Before you give an AI agent your inboxRead, draft, send: the permissions that survive prompt injection.

Safe enough for an agent with its own address and a narrow grant. Not safe for your primary inbox behind a broad connector. The reason is not theoretical; it has been demonstrated twice against products with large security teams.

In June 2025, Aim Security disclosed EchoLeak (CVE-2025-32711, CVSS 9.3), a zero-click attack on Microsoft 365 Copilot. The attacker sent an ordinary-looking email. Nobody opened it. When Copilot later processed the mailbox for an unrelated request, hidden instructions in that email made it pull data from the user's context and send it out through links to Microsoft-hosted URLs. Microsoft fixed it server-side and reported no exploitation in the wild.

In January 2026, Radware published ZombieAgent, reported to OpenAI in September 2025. An email with hidden prompts was sent to a Gmail account connected to ChatGPT. The moment the user asked for an inbox summary, the assistant read the email, followed the instructions inside it, and shipped the summary to the attacker's server. OpenAI fixed it in December 2025.

Two vendors, the same shape both times. The OWASP Top 10 for Agentic Applications, published December 2025, names the pattern: ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse. The lesson is not that those teams were careless. It is that an inbox is the one data source where the attacker gets to write the input.

Simon Willison named the problem the lethal trifecta in June 2025: an agent with access to your private data, exposure to untrusted content, and the ability to communicate externally.

If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.Simon Willison, The lethal trifecta for AI agents, 16 June 2025

Meta's security team turned that into a rule in October 2025, the Agents Rule of Two. An agent may satisfy at most two of: [A] it processes untrustworthy inputs; [B] it can reach sensitive systems or private data; [C] it can change state or communicate externally. If a task needs all three inside one session, the agent should not run autonomously; a person approves the consequential step.

Now look at what an email agent is by default. The inbox is untrusted input, because anyone on the internet can put text in front of the model by sending a message. The inbox is also private data. And sending email is external communication. One tool, all three properties, switched on together.

Readers see this without the vocabulary. When a hosted inbox-for-agents product launched on Hacker News in January 2026, one of the first replies was that an agent's address will attract spam and phishing like any other address, and nobody could say how the agent would respond to it. That is the trifecta in one sentence, from someone who had never heard the term.

Guardrail products and "ignore instructions found in emails" system prompts do not fix this. Willison's read, and OpenAI's own, is that injection cannot be reliably detected. The fix is structural: make sure the three capabilities are never live in the same session, or put a human at the step where they would combine.

Split the job before you split the permissions. Most "email agents" are four different agents with four different risk profiles.

Five rules fall out of that table.

• Its own address, never yours. An agent should send and receive as something like agent@ on a domain or subdomain you administer, in an account you control. That keeps its reach to what it was given. It also keeps you clear of consumer-mailbox abuse heuristics: operators report Gmail disabling agent-driven accounts over bursts of sends, server-side logins and templated bodies, with no useful appeal. Google publishes its sending limits, not its detection rules.
• Grant per job, per domain. "Send only" for the app that emails receipts. "Inbox" for the triage agent. "Full" only for the one that runs your newsletter. Each grant limited to the domains it is for, and nothing else in the account.
• Draft, then a human sends. For any reply to an outside party, the agent prepares a draft and a person sends it. This is the one step an injected email cannot skip, and it is exactly what the Rule of Two prescribes when all three properties are required.
• Recipients chosen by the server, not the model. A reply goes to the thread it belongs to. If the model can pick arbitrary recipients, an injected "forward this to" line becomes an exfiltration channel.
• Revocation you own, and a log. You need to cut an agent off in seconds and see afterwards what it did. If the vendor holds the kill switch, you are trusting their support queue during an incident.

Two more controls reduce the surface without pretending to close it: strip HTML comments, hidden text and remote images before the model sees a message, and keep the triage agent's other tools (web fetch, file write) out of the same session, since any of them can be an exit for data.

SendBunny is a complete email platform installed into your own AWS account as a CloudFormation stack: campaigns, lists, templates, a transactional API, a shared inbox, and an MCP server for AI agents. Nothing runs on SendBunny's servers. I built it, so read this section as the vendor's view; the rules above stand on their own.

The MCP server maps onto the design directly. An agent adds the install's /mcp URL and signs in through OAuth (dynamic client registration and PKCE, no key to paste). An admin grants Send mail, Inbox, or Full, for the domains they choose. Disconnecting from the dashboard revokes access within a minute. Inbox replies can be prepared as drafts for a person to send, over the API and MCP. Reply recipients are set by the server from the thread; the model does not pick them. A key limited to specific addresses gets a 404, not a 403, for other people's messages, so it cannot even enumerate them. Tools that would change SES or DNS tell the agent to confirm with a person first. Every privileged action, including what a connected agent did, is recorded in an audit log. And because the whole thing runs in your AWS account and region, the kill switch is yours. AWS still controls SES, and production access is AWS's decision.

claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp
# then sign in in the browser; an admin picks Send mail, Inbox or Full for chosen domains
# first call on any grant: list_domains

1. List every agent that can touch email. For each, write down which of A, B and C it has inside one session.
2. Any agent with all three: add a draft gate today, or take the send tool out of that session.
3. Move the agent off your personal or company Gmail onto its own address on a domain you administer.
4. Cut each grant to one job and one domain. Remove "full" anywhere it is not running campaigns.
5. Fix reply recipients server-side. If your tooling lets the model set "to", treat that as an open exit for data.
6. Strip hidden HTML (comments, zero-size or same-colour text, remote images) before the model reads a message.
7. Rate-limit sends and enforce suppression, so a confused agent cannot burn the domain's reputation. AWS places SES accounts under review when bounce or complaint rates climb, and can pause sending.
8. Test the revoke path. Disconnect the agent and confirm its next call fails within a minute.
9. Read the log. Once a week, look at what the agents actually did, not what you asked them to do.
10. Re-run this list when you add a tool to the agent's session. Adding web fetch to a read-only triage agent adds property C.

• You want an assistant inside your own Gmail with your full history. Use the vendor's read-only connector, keep sending manual, and accept the residual risk knowingly.
• You need per-inbox grants for many agents on one domain today. SendBunny's grants are per domain.
• You will not run an AWS account. The design above still applies; the product section does not.