Frequently asked questions

No. AMMP is not a mail transport, not agent-to-agent RPC, and not a policy language. It specifies the seam between an agent's connector and a trusted runtime that does the mailing. Between organisations there is only ordinary email, over standard protocols.

No. AMMP adds nothing to the wire, so a counterparty needs nothing but an email address. It can be a person with an inbox, a person with an assistant, or its own agent, with AMMP or without. One side can start today, and the other side changes nothing.

No, and it doesn't claim to. It assumes the agent will sometimes be fooled and limits what a fooled agent can do by email. A trusted runtime can hold a pretext back before the agent sees it. If one gets through, the agent can only ask to reply, and the runtime decides. AMMP governs the email channel only. The agent's other tools need their own safeguards.

Yes, just as with DKIM. A signature is a verifiable identifier to hang reputation on, not proof of legitimacy. Today AMMP's signed statements run only between configured peer runtimes. Extending verification to any recipient, and building reputation on it, is whitespace. See Identity.

Only what the runtime delivers into its inbound/ tree. Each delivered message carries runtime-asserted labels, such as sender standing and attachment dispositions. A message the runtime quarantines produces no notice at all (§ Inbound). Attachment bytes are published only for attachments the runtime marks clean, and that label is the runtime's assertion, not a scanner verdict.

It can name anyone, since every request names its recipients. It can't decide who actually receives anything. The runtime evaluates recipient policy over exactly the recipients it will transmit to, and it never adds or substitutes one (§ Submit Request).

The request results in queued_for_human. It is never silently sent and never silently dropped (§ Result). A recipient that policy permits is accepted without a human, so a person is involved only for the exceptions.

Then the trust boundary has moved. The runtime is the one trusted party by design, so that's where hardening belongs, and it's a much smaller, more auditable target than a model. AMMP's invariant is that no security property depends on the agent or connector behaving.

Because a file drop carries no capability. An API, an RPC endpoint or a queue is a live capability: invoking it is itself the grant, so its security rests on authenticating each call and on the client behaving. A file written into a directory has no callee, no session and no side effect until a separate, trusted process chooses to read it. The agent's only outbound act is to write an inert request into a runtime-owned namespace. The runtime reads the request, validates it, applies policy and writes exactly one result.

From the mail side, a proxy is what the runtime is: it holds the credentials, speaks the mail protocols and applies the policy. AMMP is the other side of that proxy, the contract between it and the agent it serves. A proxy on its own still has to decide what the agent sees, how the agent asks to send, and what it is told afterwards. AMMP specifies exactly that, so that a runtime and a connector built by different parties can agree on it and be tested without each other present.

They sit at different layers. In the Claude Code and Codex connectors, the agent sees ordinary MCP tools, and AMMP is the specification behind them. A2A connects agent services directly. See MCP, A2A and AMMP.

Yes, if a connector exists for it or you write one. Two are public: one for Claude Code and one for Codex, and both have run in the same fleet against the reference runtime. A connector needs no credentials, and the fixtures let you prove conformance without the other side present.

No. It is an individual Internet-Draft, draft-rapp-ammp-00, posted on 22 October 2026. No working group has adopted it, and nothing in it is settled. See AMMP at the IETF.

Because the problems it touches are interoperability problems. Agent platforms and mail infrastructure are built by different parties and need a common boundary, and mail from agents will need sender identity that recipients elsewhere can check. Neither works if one company decides it. We want review, collaborators, and an open process to own the result.

It's a fair question, and we'd like the community's view. The boundary is where independently built components meet, its peer profile already carries signed statements between hosts, and agent sender identity in email is plainly IETF territory. It may turn out that the IETF piece is the cross-organisation identity, and the local boundary belongs in an applicability statement. See AMMP at the IETF.

No. The draft has been through several internal revisions, because its reference implementations were built alongside it, but it is one team's thinking. The open questions its authors already know about are listed in the draft and tracked as issues for -01 (the milestone). We expect review to change it: its terminology, its versioning, and possibly its scope.

Until October 2026 the protocol was AMAP, the Agent Mailbox Access Protocol. It was renamed the Agent Mediated Messaging Protocol before its first submission: "mailbox access" named only its first channel, and the contract mediates an agent's correspondence, mail and peer traffic alike. The acronym AMAP was also already taken by an expired 2003 draft. Nothing on the wire changed: no document carries the protocol's name, the repositories keep their amap- names, and the two header fields the peer-origin profile defines keep theirs.

The AMMP specification, schemas, fixtures and reference implementations are published under the Apache License 2.0. Proofpoint originated AMMP, and it is open to every implementer. No one needs a particular vendor's runtime to conform or to interoperate. Today changes are made in the public repository; if the IETF takes up the work, a working group will hold change control. See Get involved.