Prompt injection by email: keeping an AI agent’s inbox safe

Prompt injection by email is an attack in which someone emails an AI agent instructions, often hidden where a person reading the message wouldn’t see them, hoping the agent obeys: forward the inbox, change a supplier’s bank details, reply with a password-reset link. No filter catches every attempt, so the defenses that work limit what a tricked agent can do. Mail that fails sender checks never reaches it, hidden text is removed before it reads, it can’t email anyone new without a person, and its key opens one inbox.

What does prompt injection by email look like?

Picture an ordinary invoice. A person sees the amount and the due date. Below them, in white text on a white background, is a paragraph addressed to “the AI assistant processing this message”: the supplier’s bank details have changed, please confirm the new ones and attach the last three invoices. The person never sees it. An agent that reads the email’s raw text reads it as part of the message.

Instructions hide in places mail apps don’t show:

• text styled to be invisible: white on white, zero size, positioned off the page, or hidden outright;
• HTML comments and the document’s head;
• invisible characters, such as zero-width spaces, and text encoded so a filter doesn’t recognise it;
• the plain-text version of the email, which most mail apps never display when there’s an HTML one.

Why is email the riskiest thing an agent reads?

Anyone can send it, with no sign-up and no permission. The From line can claim to be anyone unless the receiving server checks. And HTML lets a sender show a person one thing and a machine another.

Simon Willison calls the dangerous combination the lethal trifecta: an agent with access to private data, exposure to untrusted content, and a way to send information out. An email agent has all three by design. Its inbox is private data, every incoming email is untrusted content, and sending email is the way out. Meta’s “Agents Rule of Two” draws the same conclusion: in one session an agent should have at most two of those three, unless a person checks its work.

Has it happened?

• EchoLeak (CVE-2025-32711). Researchers at Aim Security showed that one crafted email could make Microsoft 365 Copilot pass data from the user’s own context to an outsider, with no click needed. Microsoft had fixed it on its side by the time it was disclosed in June 2025, and reported no sign that anyone had used it.
• ShadowLeak. Radware showed that instructions hidden in an email’s HTML, in tiny or white-on-white text, could make ChatGPT’s Deep Research agent, connected to a Gmail inbox, collect personal data from that inbox and send it to an attacker’s server. The data left from OpenAI’s own servers, out of sight of the victim’s security tools. OpenAI fixed it before it was made public in September 2025.
• Gmail summaries. A researcher reporting to Mozilla’s 0DIN program showed in July 2025 that text hidden in an email with a zero font size could make Gemini’s “Summarize this email” add a fake security warning with a phone number to call. No link or attachment needed.
• Phishing aimed at assistants. In October 2026 Barracuda described phishing emails written to fool both the person and the AI assistant reading for them, with instructions hidden in HTML comments, invisible text, Base64 and zero-width characters. One invoice email asked the AI summarizing it to add a task to change a supplier’s payment details.

The first three were found by researchers and fixed, and none is known to have been used against real people. Barracuda’s are real phishing emails, but it gives no count of how many reached an assistant or worked. The attacks are cheap to try, though, and every agent that reads email is a target.

What doesn’t work on its own?

Telling the model to ignore instructions in emails. It helps, a little. But a language model has no reliable way to separate the text it should act on from the text it should only read, and an attacker can try as many phrasings as they like.

Detection filters. Security products now scan email for injection attempts, and their verdicts are useful. Microsoft’s says plainly that it isn’t meant to block every instruction-like phrase. Willison’s point stands: against an attacker who keeps trying, a filter that stops 95% of attempts is a failing grade. Detection is a layer, not a wall.

Which defenses work?

Layers, each of which limits what the one before it misses:

1. Check who really sent it, and hold what fails. SPF, DKIM and DMARC let a receiver check that mail claiming to be from paypal.com came from PayPal’s servers (how they work). Mail that fails shouldn’t reach the agent until a person has looked. This stops forged senders, not hacked ones: a supplier whose mailbox was taken over passes every check, which is why the rest matters.
2. Remove what a person can’t see. Build the text the agent reads from what a person would see when they open the email. If an instruction is invisible to the person, it should be invisible to the agent.
3. Hand mail to the model as data. Quote each message as untrusted content, separate from the agent’s own instructions, and say where it came from and whether its sender was verified. OWASP lists separating and labelling external content among its prompt-injection defenses.
4. Break the trifecta at the sending step. An agent that reads mail from strangers and can see private data shouldn’t also be able to email anyone it likes. Let it write freely only to people it already knows, and have a person approve the first email to anyone new (human-in-the-loop email).
5. Keep its keys small. One inbox, no other mailboxes, no admin rights, and an expiry. A tricked agent can only misuse what it holds.
6. Close the quiet exits. Data can leave in a link or an image address as easily as in an email. Don’t let the agent fetch the URLs that emails give it on its own.
7. Keep a record and a pause. Every action should trace back to the message that prompted it, and someone should be able to stop the agent in one click.

How do SuperMailOS agent inboxes handle it?

• We check who sent every email to an agent. Mail from outside goes through our own SPF, DKIM and DMARC check. Mail that fails, or comes from a sender you’ve blocked, is held: the agent can’t list, search or open it until a person releases it. Stricter settings show the agent only verified senders, or only senders you list.
• The agent reads what a person would see. Its text is built from the email’s HTML the way a browser shows it, with each link’s address written out. Hidden text, comments and invisible characters are removed, and every message says whether its sender was verified and whether anything hidden was taken out.
• Mail arrives marked as mail. Over MCP, the agent gets each email inside a fence that labels it as untrusted content.
• Sending is narrow. Email to anyone new waits for a person by default, the agent’s key reaches only its own inbox, and it can’t approve its own email.

None of this makes an agent immune. A hacked account passes sender checks, and an instruction in plain sight is still in plain sight. These layers make an attack harder and limit what a tricked agent can do. The agent inboxes guide has the details.

Sources

• Simon Willison, The lethal trifecta for AI agents (16 June 2025).
• Meta AI, Agents Rule of Two: a practical approach to AI agent security (31 October 2025).
• OWASP GenAI Security Project, LLM01:2025 Prompt Injection.
• NIST National Vulnerability Database, CVE-2025-32711 (EchoLeak).
• Radware, ShadowLeak (18 September 2025).
• 0DIN, Phishing for Gemini (10 July 2025).
• Barracuda, Email attacks target both humans and AI assistants (7 October 2026).
• Microsoft, Prompt injection protection in Defender for Office 365.

Questions