No password. No firewall breach. No malicious link click. Just an email — processed by an AI assistant that already had legitimate access to your organization's data. That's the security lesson behind EchoLeak, the Microsoft 365 Copilot vulnerability disclosed in 2025 as CVE-2025-32711.
EchoLeak is the name given to a vulnerability affecting Microsoft 365 Copilot, publicly disclosed in 2025 and associated with CVE-2025-32711, that demonstrated how an attacker could use a malicious email as part of an indirect prompt-injection attack. Its importance came from the attack chain rather than simply the existence of a malicious prompt.
In one sentence: EchoLeak demonstrated how attacker-controlled email content could potentially manipulate an enterprise AI assistant into exposing information the attacker could not directly access — turning a trusted AI system into an unintended bridge to privileged data.
This is fundamentally different from a conventional phishing attack. The attacker doesn't necessarily need the victim to click anything. The AI itself becomes part of the processing pipeline — and the target.
The attacker prepares an email containing content designed to influence an AI assistant. The message may look relatively ordinary to a human — the malicious instructions are intended for the AI, not the reader.
The message enters through a normal communication channel. No obvious malware, no executable attachment, no traditional exploit — that's part of what makes it hard to catch with conventional email security.
An AI assistant processes the message as part of a legitimate user request or background workflow. The email becomes part of the AI's context — attacker-controlled content has now crossed into the AI's decision-making environment.
The malicious content attempts to alter how the AI interprets its instructions. The goal isn't necessarily to "break" the model — it's to influence what the model does next.
The AI may have legitimate access to email, documents, calendar data, customer information, or internal communications. The attacker doesn't have direct access to these resources — the AI does.
The manipulated AI may bring sensitive information into the attacker's reach. The AI effectively becomes a bridge: AI access → attacker-controlled instruction → unauthorized information flow.
Imagine every layer is working correctly: email security, identity security, API authentication, database authorization, network security. And yet an AI workflow can still produce an unsafe information flow — because traditional controls evaluate individual events, and everything in the chain looks legitimate in isolation.
| Security Layer | What It Sees | What It May Miss |
|---|---|---|
| Email Security | Message, sender, attachment | AI manipulation intent |
| IAM | Identity and permissions | Why the AI is using them |
| WAF | Network/application requests | Semantic prompt manipulation |
| DLP | Data movement | The AI reasoning that caused it |
| SIEM | Security events | Relationship between context and AI action |
The question that matters — why did the AI request this information? — is much harder for conventional security systems to answer. That's not a criticism of those tools; it's a gap that's specifically AI-shaped.
Microsoft Copilot isn't inherently an attacker — it's a trusted enterprise service. That's exactly what makes the attack model interesting: the AI has legitimate access, and the attacker attempts to influence how that access is used. A trusted AI system can still become an unintended attack primitive if untrusted content can influence its behavior. This isn't unique to Copilot — the underlying pattern can potentially affect many enterprise AI architectures that read external content.
Map what your AI can read, what it can access, and what happens if that content is manipulated — in minutes.
If the answer to #5 is "not yet," that deserves attention.