Limit mailbox ownership
Use a separate address and credential for each role, environment, or workflow boundary.
Minimize mailbox data and capability first, then treat content and consequential actions as separate policy decisions.
Use a dedicated mailbox per agent trust boundary, issue mailbox-scoped credentials, store secrets outside prompts and repositories, begin with receive-only temporary access, limit retrieval, validate senders, links, and attachments, require approval for durable identity or sending, log redacted identifiers, and maintain a fast pause, rotation, and revocation path.
Apply controls at identity, data, content, and action layers
Use a separate address and credential for each role, environment, or workflow boundary.
Treat bodies, links, attachments, display names, and reply context as attacker-controlled.
A message cannot grant permission to send, pay, reset credentials, or change production state.
Use a separate address and credential for each role, environment, or workflow boundary.
Treat bodies, links, attachments, display names, and reply context as attacker-controlled.
A message cannot grant permission to send, pay, reset credentials, or change production state.
Reduce historical data exposure and outbound authority while proving the workflow.
Use local tool state or a secret manager and keep the value out of prompts and logs.
Filter by mailbox, direction, time, sender context, and limit before reading content.
Require expected hosts and inspect file type and size in an isolated path.
Use human or policy approval for sending, durable claims, deletion, and external changes.
Pause the mailbox, rotate the key, remove local state, and review downstream actions.
Security is a system property. A scoped mailbox helps, but the host, MCP server, browser, secret store, application policy, and operator process still determine the outcome.
| Question | Safe answer |
|---|---|
| Whose mailbox is this? | A named agent, test, or role with a documented owner. |
| What can the credential do? | Only the mailbox and operations required for the workflow. |
| Where is the secret stored? | Outside prompt, source control, URL, and broad logs. |
| What content is trusted? | None by default; eligibility and validation are explicit. |
| What needs approval? | Durable identity, external representation, sensitive changes, and ambiguous actions. |
| How is access stopped? | Scoped pause or revocation with incident evidence. |
Product behavior is verified against the mails0 source and documentation. External comparisons link to official vendor documentation checked on 2026-08-15.
Usually no. Separate mailboxes by trust boundary so data, permissions, reputation, and revocation remain scoped.
Those controls help authenticate transport or sender domains. They do not make the message content or requested action inherently safe.
Avoid model memory and prompts. Store the key in a local tool process or approved secret manager and return only bounded results.
Start with a receive-only temporary mailbox. Move to a permanent identity or self-hosted deployment only after the workflow reaches a real email value event.