By NHI Mgmt Group Editorial TeamBased on Sentra: “EchoLeak and Indirect Prompt Injection: The Copilot Attack Surface Most Security Teams Are Missing” (May 15, 2026)

TL;DR: EchoLeak showed that a single crafted email could drive Microsoft 365 Copilot to access internal files and exfiltrate data through allowed channels, according to Sentra's analysis of the CVE-2025-32711 attack path. The deeper lesson is that prompt injection becomes a governance failure when AI assistants can reach too much data and too many outputs at once.


At a glance

What this is: EchoLeak is a zero-click indirect prompt injection in Microsoft 365 Copilot that showed a crafted email could trigger internal data access and exfiltration through permitted output paths.

Why it matters: It matters because Copilot governance is not only about patching model vulnerabilities, but about constraining what data the assistant can reach, process, and send out.


Context

EchoLeak exposed a governance gap that sits between AI prompt handling and data access control. When an assistant can ingest external content, read internal sources, and produce outward-facing outputs, the risk is not just malicious instructions but unauthorized data movement through an apparently legitimate workflow. For IAM, IGA, and data security teams, the key question is how much reach the assistant has by design.

Indirect prompt injection becomes materially dangerous when the AI system inherits the user's permissions and can act on content from outside the trust boundary. That creates a control problem that looks less like a single vulnerability and more like permission sprawl inside an AI workflow. In Copilot-style deployments, this is typical rather than exceptional unless access scope, classification, and output monitoring are deliberately constrained.


Key questions

Q: What breaks when Copilot can read too much data?

A: Prompt injection stops being a contained model issue and becomes a data exposure path. If the assistant can reach broad internal content inside a user's session, a malicious email or document can steer it toward information the user should not have operationally exposed through the AI workflow. The failure is over-scoped access, not just unsafe text handling.

Q: Why do indirect prompt injections create exfiltration risk in copilots?

A: Because the assistant can combine untrusted input, inherited permissions, and permitted output channels in one workflow. If any of those layers are broad enough, injected instructions can drive the model to retrieve sensitive data and move it out through previews, links, drafts, or agent actions. The risk comes from the chain, not one control alone.

Q: What are the signs that assistant access is too broad?

A: Warning signs include assistants returning highly sensitive content to users who do not routinely work with it, access to many disconnected repositories by default, and output paths that can send data outside the tenant without extra review. Those patterns suggest the AI has inherited permission debt from the underlying environment rather than a narrow business role.

Q: Should organisations prioritise data scoping or prompt filtering first?

A: Data scoping should come first because it reduces the blast radius even when prompt filtering misses a malicious instruction. Filters matter, but they do not fix over-privileged retrieval or unrestricted output paths. If the assistant cannot reach sensitive data, the attacker cannot exfiltrate as much when a bypass occurs.


Technical breakdown

How indirect prompt injection turns trusted content into control input

Indirect prompt injection happens when malicious instructions are embedded inside content an AI assistant is expected to process, such as email, documents, or web content. The model does not need the user to type a hostile prompt. It reads the payload as part of normal retrieval or summarisation and may follow those instructions if guardrails are incomplete. In Microsoft 365 Copilot-style systems, the risk grows because ingestion and action happen in the same trust boundary. The attack is therefore architectural, not merely linguistic.

Practical implication: Treat external content as an untrusted input stream and govern what the assistant is allowed to retrieve before it can reason over it.

Why output channels matter as much as prompt filtering

Prompt filtering only reduces one stage of abuse. EchoLeak showed that exfiltration can occur through allowed output channels, including automatically fetched links, preview mechanisms, or assistant-generated content that reaches a remote endpoint. If the system can read internal data and emit content outward, the attacker only needs one permitted channel to move sensitive material. This is why AI security controls must include egress governance, not just input sanitisation. The control boundary has to cover the full retrieve-process-output chain.

Practical implication: Map every assistant output path and block or review any channel that can move sensitive content outside the tenant.

How scoped data access changes the Copilot attack surface

The decisive variable is not whether a model can be tricked, but what it can reach if it is tricked. Scoped access limits the blast radius of a successful injection by reducing the set of documents, messages, and records available to the assistant in the user's session. That makes data classification, permission hygiene, and least-privilege access central to AI governance. If Copilot inherits broad entitlements, the assistant becomes a high-speed path through existing access debt rather than a new control layer.

Practical implication: Align assistant permissions to current business need and use data classification to keep sensitive sources out of the assistant's retrievable context.


Threat narrative

Attacker objective: Steal internal data from a Copilot-enabled Microsoft 365 tenant by abusing the assistant's trusted access and outbound channels.

  1. Entry occurred through a single crafted email that Copilot processed as trusted context without user interaction.
  2. The injected instructions steered the assistant to access internal files available in the victim's session and prepare their contents for disclosure.
  3. Exfiltration occurred through permitted output paths, allowing attacker-controlled retrieval without triggering the normal user workflow.
  4. The objective was to move sensitive enterprise data out of Microsoft 365 through a production AI assistant that was allowed to reach it.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

EchoLeak is a data access failure disguised as a prompt injection issue. The exploit mattered because the assistant could reach too much internal information once the injected content was accepted. That shifts the governance question from model behaviour alone to permission scope, data classification, and output control. Practitioners should treat AI assistant reach as a security boundary in its own right.

Prompt injection becomes materially dangerous when the assistant inherits broad user entitlements. A model with limited retrieval scope may still be tricked, but the blast radius is far smaller. EchoLeak shows that the structural weakness is not the existence of prompts but the combination of external ingestion and internal overreach. That makes least privilege for AI access a control issue, not a tuning issue.

AI governance debt is the accumulation of unscoped access across retrieval, reasoning, and output. Organisations that deploy copilots before defining what they can read, where they can write, and how sensitive data is labelled create a new class of hidden exposure. This is especially relevant where AI assistants sit on top of existing identity estates and inherit legacy permission sprawl. Practitioners should govern assistant reach before expanding usage.

Copilot security now belongs in the same conversation as data governance and identity governance. The article's real contribution is to show that AI assistants can weaponise normal enterprise access patterns without breaking traditional perimeter assumptions. That means classification, access review, and egress monitoring have to be integrated around the assistant's operating model. Teams should judge AI safety by reachable data, not by model intent alone.

What this signals

EchoLeak shows that AI assistant governance belongs in the identity stack, not only the model stack. Once a copilot inherits user permissions, the practical control point becomes what that identity can retrieve, label, and export through the assistant. IAM and IGA teams should therefore treat AI access scope as part of entitlement governance, especially where the assistant sits on top of existing Microsoft 365 permissions.

Assistant blast radius is the named concept practitioners should monitor. It is the combined reach of retrievable data, permitted outputs, and connected agents. The smaller that blast radius, the less damage a prompt injection can do; the larger it is, the more one malicious input can become a broad disclosure event.


For practitioners

  • Scope assistant access to the minimum retrievable data set Restrict which sites, mailboxes, libraries, and message sources Copilot can query so a successful injection cannot reach broad internal content.
  • Classify sensitive content before enabling assistant retrieval Apply sensitivity labels and DLP policies so confidential material stays out of the assistant's context for users without a valid need to know.
  • Review every outbound Copilot channel Map preview links, automatic fetch behaviour, email drafts, document links, and agent write-back paths so exfiltration routes are identified and controlled.
  • Baseline and alert on unusual AI-generated disclosures Use output monitoring to detect sensitive content appearing in unusual user, channel, or volume patterns that suggest the assistant is being steered.
  • Assess Copilot Studio agents separately For each agent, document what external content it ingests, what internal data it can access, and what external actions it can take before production use.

Key takeaways

  • EchoLeak is important because it reframed Copilot security as a governed data access problem rather than a one-off prompt bug.
  • The practical risk comes from the combination of inherited entitlements, external ingestion, and legitimate outbound channels.
  • Scoped retrieval, classification, and egress monitoring are the controls that materially reduce the blast radius of AI assistant abuse.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-04 — Insecure AuthenticationThe article shows how trusted AI access paths can be abused once the assistant accepts hostile input.
NHI-05 — Overprivileged NHIEchoLeak's impact depended on the assistant reaching more internal data than it needed.
NHI-06 — Insecure Cloud Deployment ConfigurationsThe exfiltration path relied on permissive cloud and tenant settings that allowed broad retrieval and output.
Recommendation — Treat assistant trust boundaries as authentication boundaries and restrict what the model can act on. Reduce Copilot entitlements to the smallest workable data set and remove inherited excess access. Harden tenant and application settings so assistants cannot use default cloud paths for disclosure.
OWASP Agentic AI Top 10ASI02 — Tool MisuseThe attack used allowed assistant capabilities and output channels in unintended ways.
Recommendation — Constrain tool and output permissions so injected instructions cannot repurpose allowed capabilities.
MITRE ATT&CKTA0006;TA0010 — Credential Access; ExfiltrationThe incident maps to data access abuse followed by outbound exfiltration through permitted channels.
Recommendation — Map the chain to credential access and exfiltration techniques when tuning detections and response playbooks.

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.
  • Agent Blast Radius: Agent blast radius is the amount of damage an AI agent can cause if it is compromised, misconfigured, or behaves unexpectedly. It includes the systems, data, identities, and actions the agent can reach through its permissions, tool access, and network paths, and is reduced by least privilege, segmentation, and strong controls.
  • Data Access Scope: Data access scope is the defined boundary of data an identity, application, or AI agent is allowed to reach. It should be based on purpose, sensitivity, and least privilege. Without a clear scope, agents can drift into overexposure, creating compliance, confidentiality, and operational risks that are difficult to detect early.
  • Egress Governance: Egress governance is the control of where systems are allowed to send outbound traffic, combined with detection when behaviour changes. In CI/CD, it helps reveal or block exfiltration attempts because malicious actions often become visible only when they reach unusual destinations.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, machine identity security, IAM, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the broader security programmes that now include AI assistants.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org