Prompt injection email attacks: when reading a message is the attack
A prompt injection email needs no click to exfiltrate your data. Why telling an assistant to behave is not a control, and what actually stops it.
A prompt injection email attack does not require the victim to type anything. In 2025 researchers disclosed EchoLeak (CVE-2025-32711), where a single crafted email caused zero-click data exfiltration from Microsoft 365 Copilot: hidden instructions were processed during retrieval, bypassed the cross-prompt injection classifier, and needed no user action and no authentication. The assistant read the message, as designed — and that was the whole attack.
What is a prompt injection email attack?
An attack where untrusted text the assistant merely reads is treated as an instruction to follow. The documented cases share that shape:
- EchoLeak (CVE-2025-32711) — one crafted email, zero clicks, data exfiltrated from M365 Copilot; classifier bypassed, no authentication needed — Vectra AI
- Reprompt (CVE-2026-24307) — single-click exfiltration from Copilot Personal via a crafted URL parameter, with zero prompts entered by the user
- Superhuman AI email exfiltration — documented by PromptArmor, January 2026
- ~4,000 developer machines compromised after a prompt injection in AI-powered GitHub Actions issue triage led to a malicious npm package installing a persistent daemon, exposing credentials, SSH keys and cloud tokens (February 2026)
That last chain is worth sitting with: it began with untrusted text in a bug report and ended with production secrets on thousands of machines.
Why can't the model just ignore malicious instructions?
Because it receives one stream of text and has no enforced way to tell the categories apart. Operator instructions, the user's request and fetched content — an email body, a document, a web page, an issue description — all arrive as text. When fetched content contains something shaped like an instruction, there is a real chance it is treated as one. This is the defining property of indirect prompt injection: the payload does not come from the user, it comes from the data.
That is why "we told it not to follow instructions in emails" is not a control. The attacker writes the text. They can write it politely, in a language you did not test, split across several messages, in white-on-white HTML, or inside a document retrieved later. Defending by instruction means defending against every phrasing an adversary can invent, forever, with the model as judge.
It is the same structural lesson as AI agent guardrails, approached from the attacker's side. There the model went wrong on its own; here an outsider makes it go wrong deliberately. Both are defeated by the same thing, and neither is defeated by better wording.
What actually defends against prompt injection?
Constraints on what the system can carry out, not on what it was asked to do.
Default deny, per routine. The agent starts with no capabilities and receives only what this routine needs. An injected instruction to email the customer list fails at the sending step if sending was never granted.
Credentials outside the model context. If a key or token is in the context window, injected text can ask for it back and any exfiltration path will carry it. A model cannot disclose what it was never shown.
A human gate on outbound and irreversible actions. Injection needs an exit — an email, a request, a commit. A person at that step turns a silent compromise into a question someone has to answer out loud.
Treat retrieved content as hostile input. Not because most of it is, but because the cost of assuming otherwise is set by the worst message you will ever process. Ordinary security practice for user-supplied data; AI systems get no exemption because the data arrives as prose.
Watch the exits. Data cannot leave through a channel that does not exist. Restricting where an agent can send anything is often more tractable than controlling what it might be persuaded to say.
Kvantia Harness is a supervision layer for an AI worker on a Windows PC your business controls, built on exactly these constraints: capabilities are granted per routine rather than broadly, credentials stay outside the model context, and outbound or irreversible steps wait for human approval. It does not make injection impossible — nothing does — but it limits what a successful injection can reach. The security model sets out each control and its honest limits.
What should you ask a vendor?
If a message it processes contained perfect instructions to do the worst possible thing, what would physically stop it?
An answer about training, classifiers or system prompts describes a filter that has already been bypassed in named, numbered CVEs. An answer about capabilities never granted, credentials never present and an approval never given describes something an attacker cannot write their way around.
Classifiers are still worth having — EchoLeak bypassed one, which argues for defence in depth rather than removing the layer. But a filter is a probability and a missing capability is a certainty. Put what you cannot afford behind the certainty.
None of this argues against letting AI read your email. It argues for deciding in advance, and in the execution path, what it may do afterwards — the same decision that separates a controlled routine from an uncontrolled one in the AI audit trail.