The security review questions an email agent should survive
Sooner or later someone in security asks what this thing can send and to whom. The questions are predictable, and most of them have infrastructure answers rather than policy answers, which is good news: you can build the answer instead of writing a paragraph about it.
5 min read
This is the review as it usually goes, with what a strong answer looks like.
Identity and access
Who is this agent, and can you prove what it sent? The answer you want is one identity per agent, one key, and an audit trail that records every message in and out against that identity with the key that sent it. "One of our agents" is not an answer, and the reason is in agent inbox or shared mailbox.
What can the key reach? One mailbox, and the contacts, notes, and secrets that agent was granted. Not the workspace, not other agents' mail.
How do you revoke it? One key, revoked, with the rest of the fleet unaffected. The full response runbook is in keys, scope, and what to do the day one leaks.
Where does the key live? A secret manager, injected at runtime, never in a prompt or a repository.
The sending surface
Who can it email? Two sub-questions worth separating: who it can reply to, which is anyone who wrote to it, and who it can contact first, which should be a smaller and more deliberate set. Whitelist mode removes the anonymous case entirely where the counterparties are known.
What stops it emailing a thousand people? Structural limits: five recipients per message, a daily and monthly send allowance, per-key rate limits, and duplicate-content and velocity tripwires on cold sends. Not prompt instructions.
What happens when a limit is hit? A refusal with a reason the agent can act on rather than a silent failure or a retry loop.
Can it be talked into sending? Honest answer: partially, which is why the controls sit under the model. Point at the architecture in prompt injection by email: untrusted text never shares a call with privileged tools, and first contact with a new domain is alerted on.
| Question | Weak answer | Strong answer |
|---|---|---|
| Who can it email? | "It only replies to customers" | Whitelist mode, plus alerting on first sends to new domains |
| What limits sending? | "The prompt says not to" | Recipient cap, allowances, rate limits, tripwires |
| Can you attribute a message? | "We could check the logs" | Per-identity audit trail, per message, with the key that sent it |
| What if the key leaks? | "We would rotate it" | Revoke, read the identity's sent mail, rotate granted secrets, redeploy |
Data handling
What personal data does it touch? Message bodies, contact records, recorded facts, attachments. All of it personal data, all of it subject to retention and deletion obligations, per the compliance floor.
Where does it go? Which model provider sees message content, under what terms, and whether anything is retained by them. The three legs of that flow are mapped in where the mail actually goes. Have that answer written down before you are asked, because it is the question that stalls reviews.
What is retained, and for how long? A retention period per category, decided rather than defaulted. Storage is part of your plan and unlimited retention is a choice you should be making deliberately.
Can you answer a deletion request? Across the mailbox, the contact record, your own systems, and any traces. If that takes more than an afternoon, it is a finding.
What is in your logs? The right answer is ids, actions, sources, and refusal reasons. Message bodies in a log aggregator is a finding, and a fair one.
Our side of the processing relationship is in the data processing addendum, with sub-processors listed at subprocessors and the platform's own posture at security.
Failure and oversight
How do you know it is working? Synthetic checks, because an agent that stopped answering looks exactly like a quiet inbox. Volume, bounce, and complaint alerting, per what to monitor in production.
How do you know it is answering correctly? Correction rate, reopen rate, and a human reading a sample of threads weekly. If the answer is only "we have not had complaints", that is not monitoring.
What is the kill switch? Revoke the key, which stops that agent and nothing else. Test it once, and have the rest of the runbook ready, per when the agent sends something it should not have.
Who owns it? A named person who reads its mail weekly. An agent nobody owns will drift, and reviewers are right to ask.
The questions worth asking yourself first
Before the review, run these. They are the ones that produce findings.
- What is the worst message this agent could be persuaded to send, using only what it can reach today?
- If a stranger emails it right now, what happens?
- If the key leaked an hour ago, what would we know, and how?
- What did it send yesterday, and can I see that in under a minute?
- What data would we have to produce for a deletion request, and where is it?
- Which of our controls is a prompt instruction pretending to be a control?
Question six catches most of what a reviewer will catch, and it is cheaper to answer yourself.
When the answer is "we accept that risk"
Some of it will be, and that is a legitimate outcome as long as it is written down, owned by someone with the authority to accept it, and bounded. "The agent can contact new domains because outreach is its job, and we accept that, with a daily cap, alerting, and a weekly review" is a real answer. "It probably will not" is not.
Questions
- What does a security review of an AI email agent cover?
- Identity and key scope, what the agent can send and to whom, what limits are structural rather than prompted, personal data handling and retention, monitoring, the kill switch, and named ownership.
- What is the most common finding?
- Controls that are prompt instructions rather than enforced limits, followed closely by message bodies in application logs.
- How do I prove what an agent sent?
- A per-identity audit trail that records every message with its thread and the key that sent it. This is why one key per agent matters before an incident, not after.
- What is the kill switch for an agent?
- Revoking its key, which stops that agent and leaves the rest of the fleet running. Test it once so you know it works.
- What should logs contain?
- Message ids, actions taken, sources grounded on, and refusal reasons. Not message bodies, which are personal data with retention obligations you did not intend to take on.
- Who should own an agent?
- A named person who reads a sample of its mail weekly. Unowned agents drift, and a reviewer asking who owns it is asking a fair question.
Give your agent an address it can answer from.
Create an inbox