Is it safe to let an AI agent read my email?

It depends entirely on whether reading can cause acting. The safe design is that inbound mail can't start work directly — it creates a pending request needing confirmation from the account owner — and that anything the resulting task would change still requires separate human approval.

Can someone spoof my email address to make an agent run tasks?

Not in a design where mail creates a pending request rather than a task. A forged email produces an unsolicited confirmation request in the real owner's inbox, which is a warning rather than a running task.

What about prompt injection from email content?

It's a separate problem from spoofing and needs a separate answer: email content should be treated as data to reason about rather than instructions to follow, and an approval gate on every proposed change means injected text still can't reach the account on its own.

Does confirming an email task approve everything it does?

It shouldn't, and here it doesn't. Confirming starts the task; each account change it then proposes goes through the normal approval gate separately.

Are my email bodies stored by the agent?

Not in our implementation — bodies are re-fetched on demand rather than stored, and a read is checked against your organization first so one org can't read another's messages out of a shared inbox.

Concepts

Is it safe to let an AI agent read your email?

TL;DR

Connecting an AI agent to email joins the two things that make an agent risky: an untrusted input channel and the ability to act. Anyone can put your address in a From header, and anyone can put instructions in an email body hoping the agent reads them as commands. Those are different attacks needing different defences, and a design that only handles one of them isn't safe. Here's the threat model and the checks worth demanding.

Two different attacks, often confused

Attack	What the attacker does	What actually stops it
Sender spoofing	Forges your address in From, hoping the agent treats it as you	Never letting inbound mail start work directly — a second factor the real owner controls
Prompt injection	Writes instructions in an email body hoping the agent follows them as commands	Treating email content as data, never as instructions, plus an approval gate on anything it would change

Solving one doesn't solve the other. Verified sender identity does nothing about malicious text inside a legitimate email, and injection defences don't help if anyone can impersonate an authorized sender.

Why a confirmation step is the right answer to spoofing

Email authentication (SPF, DKIM, DMARC) helps, but it's uneven in practice and not something you'd want to be the only thing between a forged header and real spend on a real ad account.

The stronger design is structural: inbound mail never starts a task at all. It creates a *pending* record and replies to the address in question with what would run and where. A forged email then produces an unsolicited confirmation request in the real owner's inbox — a warning, not a running task. The attacker gets nothing, and the owner learns someone tried.

Why the approval gate has to sit underneath it

Confirmation authenticates the *request*. It says nothing about whether what the agent then decides to do is correct — and an email body full of attacker-written text is exactly the kind of input that can push a model somewhere unintended. So the confirmation can't be the last checkpoint. Every account change the task proposes has to stop for human approval independently, the way it would for work started anywhere else.

Confirming that a task should run and approving what it does are two separate decisions. A design that collapses them into one has removed a checkpoint precisely where an untrusted channel makes it most valuable.

What to check before connecting an agent to email

Can inbound mail start work on its own? If yes, spoofing is a direct path to action.
Is the confirmation a real second factor — sent to the account owner, expiring, single-use — or a formality anyone in the thread can satisfy?
Do proposed changes still need separate approval after the task starts?
Is email content treated as data rather than instruction? Instructions inside a body should be context to reason about, not commands to obey.
Are non-member senders handled deliberately? Automation that fires on outside mail should be something a signed-in person set up on purpose, with limits.
Does it reply into threads with outsiders in them? Sending a report back into a client's thread can disclose your data to them — that should be opt-in.
Are message bodies stored, and who can read them back? A shared inbox with per-organization data in it needs ownership checks on read, not just on write.
Are there rate limits? Without them, a single spoofed address is a cheap way to burn your budget on unwanted runs.

How Agent Planners answers each of these

Check	What we do
Can mail start work directly?	No — it creates a pending intent and replies asking for confirmation
Is the confirmation a real second factor?	Reply in-thread, or a signed one-click link that expires; confirming is a one-shot atomic flip, so a duplicate delivery can't start it twice
Do writes still need approval?	Yes — confirming starts the task; every proposed account change goes through the normal approval gate
Non-member senders	Ignored, unless a rule a member authored in-app matches — that authorship is the consent
Replying into outside threads	Off unless enabled per rule
Rate limits	10 email tasks per address per 24h; 10 fires per rule per day; at most 3 rules per email
Message storage	Bodies aren't stored — they're re-fetched on demand and checked against your organization before being returned
Channel integrity	Webhook signatures verified, and the message re-fetched from the mail API rather than trusted from the webhook payload

The honest residual risk

None of this makes an email channel risk-free. A member who confirms without reading the summary has approved a task they didn't scrutinise, and a badly-scoped standing rule can fire on mail you didn't anticipate — which is why rules are capped and why the cap is low. The defensible claim isn't that nothing can go wrong; it's that no single failure — a spoofed header, a malicious body, a duplicated webhook — reaches your ad account by itself. Full detail is in the email tasks documentation, and the broader account-access checklist is in is it safe to give an AI agent access to your ad account.

Frequently asked questions

Is it safe to let an AI agent read my email?: It depends entirely on whether reading can cause acting. The safe design is that inbound mail can't start work directly — it creates a pending request needing confirmation from the account owner — and that anything the resulting task would change still requires separate human approval.
Can someone spoof my email address to make an agent run tasks?: Not in a design where mail creates a pending request rather than a task. A forged email produces an unsolicited confirmation request in the real owner's inbox, which is a warning rather than a running task.
What about prompt injection from email content?: It's a separate problem from spoofing and needs a separate answer: email content should be treated as data to reason about rather than instructions to follow, and an approval gate on every proposed change means injected text still can't reach the account on its own.
Does confirming an email task approve everything it does?: It shouldn't, and here it doesn't. Confirming starts the task; each account change it then proposes goes through the normal approval gate separately.
Are my email bodies stored by the agent?: Not in our implementation — bodies are re-fetched on demand rather than stored, and a read is checked against your organization first so one org can't read another's messages out of a shared inbox.