Automatic
Bounded retrieval for an active workflow
Read the expected current code or status when scope and filters are already established.
Security guide
Treat every email as untrusted input to the agent.
Transport checks can confirm where a message came from. They cannot make instructions inside the message safe, relevant, or authorized for the current workflow.
Direct answer
Defend against email prompt injection by separating message transport from workflow authority. Give the agent a dedicated scoped inbox, select messages with trusted application state, retrieve only the fields needed for the current step, label all email content as untrusted data, validate links and attachments outside the model, and require policy or human approval before sending, changing credentials, making purchases, deleting data, or taking unrelated external actions. Log the decision path with redacted identifiers, and provide a fast mailbox pause and key-revocation path.
Four gates between an email and an external action
Each gate answers a different security question. Passing one does not bypass the next.
- 01Transport gate
Verify the mailbox route, event source, and delivery integrity.
- 02Eligibility gate
Match mailbox, workflow, sender context, recipient, and time.
- 03Payload gate
Extract and validate the minimal code, link, text field, or file.
- 04Authority gate
Check application policy and approval before acting externally.
Threat model
A correctly delivered email can still contain hostile instructions
An attacker may send a message that asks the agent to ignore policy, reveal secrets, open an unrelated link, upload a file, forward private mail, change account recovery, or contact another person. The instruction can appear in plain text, HTML, quoted history, a calendar-like block, an attachment, or a page reached through a link.
The message may also come from a legitimate account that was compromised or from a familiar service whose content includes user-controlled fields. SPF, DKIM, DMARC, webhook signatures, and provider authentication help establish transport and domain evidence. They do not prove that every sentence is safe or that the requested action is authorized.
The security objective is not to make the model perfectly classify malicious prose. It is to make untrusted prose unable to grant new authority or escape the workflow boundary.
| Signal | What it can establish | What it cannot establish |
|---|---|---|
| Webhook signature | Expected service delivered the event | Message instructions are safe |
| DKIM or domain alignment | Domain-level authentication evidence | The sender account or content is benign |
| Known display name | A familiar string is visible | Identity or authorization |
| Thread relationship | The message belongs to a conversation | Every new request is approved |
Context control
Select and extract before the content reaches the model
Start from trusted workflow state: the mailbox identifier, expected direction, trigger time, sender or domain context, and required result type. Query message metadata first. If the task only needs a six-digit code, return the candidate code with message ID and timestamp rather than the full HTML body and entire conversation.
For a confirmation link, parse the URL in trusted code, require HTTPS and an allowed host, reject embedded credentials and unexpected redirects, and return a normalized target. For attachments, inspect size, type, filename, and content in an isolated parser. The model should receive a summary or extracted fields only after policy checks pass.
This is both a security and quality improvement. Smaller context reduces the chance that quoted text, signatures, tracking markup, and unrelated thread history distract the agent or override the current task.
-
01
Use trusted state to query
Start with mailbox, workflow, recipient, time, and expected sender context.
-
02
Inspect metadata
Select one current candidate without exposing the full payload.
-
03
Extract in trusted code
Validate code shape, URL host, attachment type, or structured field.
-
04
Return a labeled result
Tell the model it is untrusted data and constrain how it may be used.
Tool design
Expose narrow operations instead of a universal mailbox tool
A tool named read_any_email_and_act hides too much authority. Prefer separate operations for list metadata, get one message, wait for a current code, retrieve an approved attachment, draft a reply, request send approval, and send an approved message. Give each operation the smallest credential and result schema it needs.
MCP servers and local agent tools should keep secrets in the tool process, not return them in model-visible output. Tool descriptions should state that message content is untrusted and should not be treated as instructions. The host application remains responsible for user consent, tool enablement, and confirmation behavior.
- Separate read, draft, approve, and send operations.
- Use mailbox-scoped credentials instead of operator keys.
- Cap query limits and attachment sizes in trusted code.
- Make denied and ambiguous outcomes explicit tool results.
Incident response
Prepare for the day a malicious message gets through
Record which message and extracted field informed each action, using restricted identifiers rather than copying sensitive bodies into general logs. Preserve approval evidence, tool calls, external request identifiers, and final state. This lets the team reconstruct the decision without retaining every mailbox payload indefinitely.
The immediate response should be narrow: pause the affected mailbox or tool, rotate its credential, stop pending outbound actions, and inspect downstream transitions. Search for the same sender, link host, attachment hash, or content pattern across authorized scope. Restore service only after the policy or parser gap is understood.
| Incident step | Action | Evidence |
|---|---|---|
| Contain | Pause mailbox or disable risky tool | Scope and effective time |
| Revoke | Rotate credential and invalidate sessions | Key identifier and callers |
| Trace | Map message to tool calls and external actions | Message, workflow, and request IDs |
| Repair | Tighten filter, parser, policy, or approval | Regression test and deployment proof |
Implementation judgment
Do not ask the model to be the security boundary
Models can help classify and summarize, but they should operate inside a system that already limits identity, data, tools, and authority. The durable defense is a sequence of trusted gates, a narrow tool surface, and an operator who can stop and investigate one mailbox without disabling the entire product.
Evidence
Sources and product scope
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
- mails0 source repositoryImplementation, license, and deployment source
- OWASP GenAI prompt injection guidancePrimary community security guidance for prompt injection risks and mitigations
Questions and answers
Questions that come up in practice
Does DKIM prevent email prompt injection?
No. DKIM can provide domain-level authentication evidence. It does not make the message body, link, attachment, or requested action safe.
Should an AI agent read the complete email thread?
Only when the task needs that context. Prefer metadata selection and bounded extraction so quoted history and unrelated instructions do not enter the model context.
Can prompt injection be solved with a better system prompt?
A prompt can clarify behavior but should not be the only control. Enforce scope, extraction, link and file validation, action policy, approval, and revocation in trusted application code.
Start with a bounded inbox
Prove the smallest useful email loop.
Start with one scoped inbox and one expected message. Add durable identity, sending, and operational complexity only when the first loop works.