The three risks
An agent that reads a narrow inbox and can only draft is a small risk. An agent with full access to your personal inbox and permission to send is a large one. The difference is in three places.
Prompt injection. An email is text a stranger chose. A line hidden in its HTML, or written in plain view, can tell the agent to do something you did not ask for: forward a thread, reply with a code, click a link. The model has no reliable way to tell your instructions from the sender's. Prompt injection in email covers the tricks and the defences.
Exfiltration. The damage an injection does is mostly what it can send out. An agent that reads your inbox and can send email can be asked to send your inbox to somebody else. The read on its own is far less dangerous than the read plus the send.
Reach. Whatever the agent can see, an injection can try to use. If it reads your whole Gmail, that is your bank statements, your password resets and your one-time codes, not only the mail the task was about.
Ways to reduce each
Give it its own inbox, not yours
Most agents do not need your inbox. A support agent needs support@; an agent that books suppliers needs the replies from suppliers. Give it an address of its own and it can only ever read what was sent there. How to give your AI agent its own email address shows how, with Pidgeon or another agent inbox API.
When the agent does need your mail — triage, a daily summary — forward a filtered subset to its address rather than granting OAuth to everything. A Gmail filter that forwards invoices to the agent's address gives it the invoices, and nothing else; the Gmail forwarding guide sets one up.
Let it draft, not send
The single biggest reduction in risk is taking the send away. In Pidgeon, a key with draft access reads, labels and writes drafts, and every path that puts mail on the wire answers 403: sending, replying, forwarding, scheduling. A person reads the draft and sends it. Approving drafts walks through it.
For an agent that has to send, narrow who it can send to:
send_policy: "reply_only"makes an address unable to start a conversation with somebody who has not written first.send_approval: "first_contact"holds a first email to somebody new for a person to approve.- A reply or forward in a thread where a message from the last 72 hours tried to give the agent instructions waits for a person, on every address.
Screen what it reads
Every inbound Pidgeon message carries a Firewall verdict that names hidden text, instructions addressed to a model, fake system turns, look-alike senders and requests for secrets. At an address that holds, which every address in a new workspace does, a flagged message is kept for a person and no key can read it until it is released. The model reads a cleaned text with what a person cannot see removed.
Keep a person able to take over
Every conversation in Pidgeon has an owner, agent or human. When a person replies in a thread or takes it over, the agent's key is refused there until the person hands it back. If something looks wrong, the person stops the agent in that conversation without revoking anything else.
What none of this does
No screening catches every injection: a polite, visible instruction may fire no rule at all. A clean verdict means no rule fired, not that the email is safe to obey. And these controls protect the inbox, not the agent's other tools. If it can also run a shell or browse, an injection can try those. The rule that holds across all of them is the same: give the agent the narrowest access that does the job, and make the dangerous actions need a person.
A checklist
- The agent reads an address of its own, or a filtered forward, not your whole inbox.
- Its key is limited to that address.
- It drafts, or it sends only under
reply_onlyor first-contact approval. - Suspicious mail is held for a person.
- A person can take any conversation over, and the agent stops there.
- Its other tools are as narrow as its email.
Sign up and the fourth is on from the first message; the Firewall guide and the keys guide cover the rest.