EchoLeak shows why Copilot security is a data access problem

At a glance

What this is: EchoLeak is a zero-click Copilot vulnerability that demonstrated how indirect prompt injection can turn an AI assistant into a data exfiltration path.

Why it matters: It matters because IAM, data governance, and AI security teams now have to scope what LLM-based assistants can reach, not just patch the latest prompt injection flaw.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Sentra's analysis of EchoLeak and Copilot prompt injection risk

Context

EchoLeak exposed a broader governance gap than a single Microsoft 365 Copilot flaw. The core issue is not only whether an assistant can be patched, but whether it can reach sensitive data, ingest untrusted content, and send outputs to external destinations in the first place. In AI security and identity terms, that makes the assistant a governed access path, not just an application feature.

For IAM and data security teams, the article is a reminder that least privilege must now extend to AI-assisted workflows, internal document retrieval, and external content ingestion. Where Copilot or similar systems can see too much, prompt injection becomes a practical exfiltration route rather than a theoretical model risk.

Key questions

Q: How should security teams reduce prompt injection risk in AI agents?

A: Security teams should reduce prompt injection risk by constraining what enters the context window, limiting tool permissions, and separating untrusted retrieval content from privileged instructions. The practical goal is not perfect detection. It is to ensure that a successful injection cannot trigger wide data access, uncontrolled writes, or irreversible actions through a delegated identity.

Q: Why does indirect prompt injection create a bigger security problem than a simple model bug?

A: Because it exploits trusted workflows, not just model responses. The attacker hides instructions inside content the assistant is meant to process, then uses the assistant's own privileges and output channels to leak data or trigger actions. That makes the issue a control boundary problem across IAM, data protection, and AI governance.

Q: What breaks when an AI assistant can access private data and untrusted content at the same time?

A: When an assistant can access private data and ingest untrusted content, a small injected instruction can become a data-exfiltration path. The usual assumption that content is passive fails, because the model can interpret it as an operational command and move it into tool execution.

Q: Who is accountable when an AI assistant overshares sensitive content?

A: Accountability sits with the team that owns the policy, the attribute feeds, and the enforcement points, because ABAC only works when all three are managed together. If any one of them is missing, the organisation has not built a defensible control path, even if the model itself appears constrained.

Technical breakdown

Indirect prompt injection turns trusted content into an execution path

Indirect prompt injection happens when malicious instructions are hidden inside content the model is supposed to process, such as email, documents, or web pages. The user does not type the attack prompt directly, which makes classifier-only defenses weaker because the malicious text arrives through a legitimate retrieval path. In Copilot-style systems, the model can interpret attacker-controlled content as part of the task context and then act on it while still appearing to obey the user’s request. The key design problem is that the same input channel can carry both benign context and hostile instructions.

Practical implication: treat every retrieved content source as an input trust boundary and restrict what the assistant can ingest.

Exfiltration depends on the assistant's reachable data and output channels

EchoLeak mattered because it linked retrieval, privilege, and output in one chain. If the assistant can access internal files from the current user’s session, an injected instruction can target those files. If the assistant can also emit content through images, links, drafts, or external APIs, the attack becomes an exfiltration path instead of a harmless prompt manipulation. This is why the problem is architectural rather than purely software-specific. The security question is not whether the model can be tricked once, but whether its connected systems let it move sensitive data out of scope.

Practical implication: map every AI assistant's data inputs and outputs before production use and remove unnecessary egress paths.

Agentic extensions multiply the indirect prompt injection blast radius

Copilot Studio agents and similar tool-using systems expand the attack surface because they can ingest more external sources and take direct actions. That creates longer task chains, more dependent systems, and more opportunities for hostile instructions to survive until execution. Once an agent can write to external systems, send messages, or trigger workflows, injected content can move from model output into operational action. This is where AI governance starts to overlap with IAM, because the agent is effectively a non-human identity with delegated authority that must be scoped and monitored.

Practical implication: review agent integrations as delegated identities and limit their tool access to the minimum task scope.

Threat narrative

Attacker objective: The attacker seeks to make an AI assistant reveal sensitive internal information and relay it to an external server without raising immediate suspicion.

1. Entry occurred through a single crafted email that Copilot could ingest as legitimate context during retrieval.
2. Escalation happened when injected instructions steered the assistant toward internal files the user session could already reach and then shaped the response to carry data outward.
3. Impact came from exfiltration through allowed external channels, turning the assistant into a data leakage mechanism without user interaction.

Breaches seen in the wild

• Microsoft SAS Key Breach — Overly permissive Azure SAS token exposes 38TB of Microsoft internal data including secrets and credentials.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

EchoLeak proves that AI assistant security is now a data access governance problem. The vulnerability was patched, but the architectural lesson remains: if an assistant can reach sensitive data, it can also be induced to expose it. That shifts the control conversation from prompt filtering to scoped entitlements, labeled data, and monitored egress. For practitioners, the decisive question is not whether the model is safe in isolation, but what it can touch inside the enterprise.

Prompt injection becomes materially more dangerous when the assistant can see internal systems and talk to external ones. The attack is only useful when ingestion, privilege, and output line up in the same workflow. That makes AI assistants a governance boundary issue for IAM, DLP, and data classification teams, not a narrow application bug. The practical conclusion is that AI access paths must be reviewed like any other privileged integration.

Scoped access is the real control plane for LLM-based assistants. The article shows that patching one exploit does not eliminate the class, because the class is rooted in overbroad reach. This is where the named concept of the assistant reach boundary matters: the smaller the boundary, the less value an injected prompt can extract. Practitioners should treat reach reduction as a core security objective, not an optimisation.

Copilot Studio-style agents extend the same risk into delegated action. Once an AI system can send mail, write records, or call APIs, prompt injection can cross from disclosure into operational abuse. That brings agent governance into the same conversation as NHI oversight, because the agent is acting with delegated authority and needs lifecycle controls, approval boundaries, and telemetry. The field should now assume that any tool-using assistant is a governed identity in all but name.

The market signal is clear: AI security controls are converging with identity controls. Data access scoping, classification, and monitoring are becoming the practical defenses for assistant abuse because model-only defenses are insufficient. That aligns with the direction of OWASP-NHI and OWASP agentic guidance, and it tells security leaders to stop separating AI risk from identity governance. Practitioners should plan for shared control ownership across IAM, data security, and AI governance teams.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That gap matters because assistant and agent access decisions increasingly depend on the same identity controls covered in Ultimate Guide to NHIs , Key Challenges and Risks.

What this signals

Assistant reach boundary: the practical unit of control is no longer the prompt, but the combination of readable data, writable outputs, and delegated tools. Teams that can inventory that boundary will be far better positioned to stop prompt injection from becoming data exfiltration. The control pattern aligns closely with scoped access principles in the OWASP Non-Human Identity Top 10.

AI security programmes should now treat content classification and identity governance as a shared operating model. If an assistant can read the wrong records, the model layer cannot compensate after the fact, which means IAM and data security teams need to define entitlements before deployment. That is especially true where assistant integrations resemble governed non-human identities rather than simple software features.

The strongest programmes will measure assistant risk by blast radius, not by patch count. If an assistant can ingest external content, reach sensitive internal data, and emit externally accessible output, the organisation has already created the conditions for leakage, even if a specific CVE is fixed.

For practitioners

• Scope assistant data reach by default Review which SharePoint sites, mailboxes, documents, and data stores Copilot or similar assistants can access, then remove anything outside the user's current role. Use least privilege as the baseline for assistant-visible data rather than inheriting broad tenant access.
• Classify sensitive content before AI retrieval Apply sensitivity labels and DLP policies so high-value records are excluded from AI context unless the user is explicitly entitled to see them. Validation should cover labeled content, inherited permissions, and external sharing paths that can reintroduce the same data.
• Review external ingestion channels Limit which external emails, documents, plugins, and federated collaboration sources can feed AI assistants. Every additional ingestion route increases the prompt injection surface, so high-risk deployments should whitelist only the sources needed for the task.
• Treat AI agents as delegated identities For Copilot Studio and similar agents, document what systems they can read, what actions they can take, and what approval or logging exists for each action. That control view should sit alongside IAM and PAM reviews because the agent is effectively operating with assigned authority.
• Monitor AI output for abnormal disclosure Build detection for sensitive content appearing in AI-generated responses, especially when the output includes unusual combinations of internal terms, external links, or unexpected recipients. The goal is to catch leakage patterns that a user would not normally generate.

Key takeaways

• EchoLeak shows that prompt injection becomes a real breach path when an AI assistant can access sensitive internal data and external outputs.
• The incident underscores a control failure in data reach, not just a software flaw, because scoped access determines how far injected instructions can travel.
• Security teams should govern AI assistants like delegated identities, with least privilege, classification, and egress monitoring built into the design.

Key terms

• Indirect Prompt Injection: Indirect prompt injection is an attack where malicious instructions are hidden inside content that an AI system reads later. The model may treat that content as context rather than as hostile input, which can influence tool use, data access, or workflow actions if controls are weak.
• Assistant Reach Boundary: The total set of data sources, tools, and output paths an AI assistant can access during a session. It is the practical limit that determines how much damage a prompt injection can cause, because an injected instruction can only exfiltrate or manipulate what the assistant is allowed to touch.
• Delegated AI identity: Delegated AI identity describes an AI system that acts with permissions, credentials, or scoped authority on behalf of a business process. It matters because once an AI can initiate actions, it needs lifecycle, access, and offboarding controls similar to other governed non-human identities.
• Data Access Governance: Data access governance is the practice of deciding who or what should reach specific data based on sensitivity, business purpose, and observed access paths. It combines classification, entitlement analysis, and review workflows so access decisions reflect exposure, not just permission status.

What's in the full article

Sentra's full analysis covers the operational detail this post intentionally leaves for the source:

• A step-by-step walkthrough of the EchoLeak bypass chain, including classifier evasion and allowed-domain proxying.
• The Copilot-specific exposure conditions that determine when prompt injection can reach internal files.
• Practical guidance on scoping data sources, labeling content, and limiting external ingestion for Microsoft 365 environments.
• The agent review questions Sentra recommends before production deployment of Copilot Studio workflows.

👉 The full Sentra article covers the bypass chain, exposure conditions, and Copilot governance details.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners build the access and lifecycle controls that underpin safer AI and identity programmes.