How it works

AMAP puts the authority where the agent can't reach it

AMAP, the Agent Mailbox Access Protocol, is an open specification: a wire contract between a trusted email runtime and a connector that sits beside an agent. The runtime holds the authority. The agent can only ask.

Three zones

The runtime is the only trusted party, with an untrusted side on each flank. It guards in both directions: what reaches the agent, and what leaves.

Outside

Email, over standard protocols. It sits outside the trust boundary. A production runtime would typically use IMAP and SMTP; the reference runtime is transport-free, the specification requires neither, and AMAP adds nothing to the wire between organisations.

Trusted runtime

It holds the mail credentials and the sending identity, screens what reaches the agent, evaluates recipient policy, writes a result for every request, and keeps an audit log the agent cannot write.

Agent side

The agent runs in a sandbox and reaches only its connector, which offers ordinary MCP tools. Its only outbound act is to drop an inert request. A file drop carries no capability.

Specified · § Architecture "No security property may depend on the agent or connector behaving… A compromised agent or connector can at most write a well-formed request the runtime then refuses."

The seam: a per-agent filesystem tree

The AMAP interface is a runtime-owned filesystem namespace for each agent. It straddles the boundary: the runtime writes into inbound/ and results/, and the connector writes inert requests into outbound/. The runtime treats everything in the tree as untrusted input.

Because the channel is a filesystem namespace rather than an API the agent could call, a request grants nothing on its own. The runtime decides whether anything is sent, to whom, and how. The connector offers the agent ordinary MCP tools, so AMAP sits behind MCP rather than competing with it.

Walkthrough: the bank-detail pretext

A look-alike sender's "use these new bank details" arrives from email, outside the trust boundary.
Screening may hold it back. § Inbound A message the runtime quarantines produces no notice at all, so the agent never learns it existed. How well messages are screened is the runtime's job; the specification does not grade it.
If it gets through, the runtime delivers it into inbound/ with a runtime-asserted attachment disposition and sender standing.
The fooled agent asks to reply. Every submit request names its recipients (to is required). The agent can name anyone. It cannot reach the credentials or choose its sending identity.
The runtime evaluates recipient policy over exactly the recipients it will transmit to, and it never adds or substitutes one (§ Submit Request). A recipient that policy permits is accepted without a human.
A policy miss produces queued_for_human: never a silent send, never a silent drop (§ Result). Under an allowlist, a look-alike sender is a new external contact, so a person sees the held reply and makes the out-of-band check.

The honest edges

Where, not what

AMAP fixes where the decision is made; the deployment decides what it is. A policy that trusts whoever started a thread could let a reply to a look-alike sender through, because a look-alike domain can pass authentication for itself.

Email only

AMAP governs the agent's email authority. If the agent also holds a tool that can update a vendor record, that tool needs its own isolation and safeguards.

Not a cure for prompt injection

AMAP doesn't make delivered content safe, and it doesn't stop an agent being fooled. It limits what a fooled agent can do by email.

What AMAP is not

It is not a mail transport, not agent-to-agent RPC, and not a policy language. It fixes the vocabulary of the seam, never the computation behind it.

Also specified

Attachment dispositions. Each attachment is labelled clean, stripped, quarantined or unscanned. This is the runtime's assertion, not a scanner verdict, and bytes are published only for clean.
Exactly one result for every request the runtime consumes: accepted, queued_for_human or rejected.
Filesystem discipline: atomic writes, refusing to follow symlinks, rejecting path traversal, stripping header injection, and a single writer and single drainer.
Version refusal. A document with an unrecognised major version is refused, never guessed at. It fails closed.
Direction decides openness. Documents written by the runtime are open to extension. Documents written by the agent are closed, so an unrecognised field is rejected visibly.

For implementers Identity and open questions