For the IETF community
AMMP at the IETF
Agents are starting to take part in email: reading it, drafting it, and increasingly sending it. We think the way they do so safely, and the way their mail can be trusted across organisations, may benefit from open standards. AMMP is an individual Internet-Draft, posted in October 2026, that proposes one piece of that. We're bringing it to the IETF for review, for collaborators, and to find out whether there is interest in working on it together.
Where this is draft-rapp-ammp-00 was posted to the IETF Datatracker on 22 October 2026 as an individual Internet-Draft, with Standards Track as its intended status. No working group has adopted it, and it belongs to no stream yet. It reflects one team's thinking, one reference runtime and two reference connectors, and nothing in it is settled. We expect the community to change it, including in ways we haven't anticipated.
The problem
Email is the channel organisations already share. It crosses organisational boundaries without prior arrangement, and much of their work is requested, approved and recorded in it. Agents that do that work will need to take part in it.
Today, the common way to give an agent email is to give it a mailbox: credentials it can use, and an identity it sends as. In email, authority is carried by text, and a pretext is also text. An agent holding a mailbox can be talked into acting, at machine speed, under a legitimate identity. Its recipients have no way to tell which agent sent a message, or on whose authority.
Why now
- Platforms have begun provisioning agents with mailboxes of their own. For example, Microsoft's Agent 365 preview gives an agent an identity and a mailbox (Microsoft Learn), and Meta has said its Muse agent "will have its own email address" (Meta, September 2026).
- Agent-security work so far has concentrated on the agent's runtime and its tool calls. The agent's correspondence with people and organisations it has no prior relationship with has had much less attention.
- Interoperable conventions are easier to agree before deployments diverge than after.
Why it may need a standard
Two interoperability problems, and they are different:
Inside an organisation
The agent and the trusted component that holds its mail authority are built by different parties: agent platforms on one side, mail and security infrastructure on the other. If each pairing needs its own integration, safe designs don't spread. AMMP proposes a common boundary between them, which either side can implement and test without the other present.
Between organisations
When an agent's mail arrives elsewhere, the recipient needs to know which agent sent it, for whom, and what that should be taken to mean. Domain authentication (SPF, DKIM, DMARC) proves the sending domain, not the agent. That gap sits squarely in the email-authentication work the IETF already does. AMMP doesn't solve it; it identifies it.
The question we expect first
"AMMP is a local interface over a filesystem, and it adds nothing to the mail between organisations. Why is that IETF work?"
It's a fair question, and we'd like the community's view rather than to argue it. Our reasons for thinking parts of it may belong here:
- The boundary is where independently built components meet. The IETF has specified interfaces between independently built mail components before, such as LMTP (RFC 2033) for local delivery.
- It doesn't stay local. The draft's optional peer-origin profile carries signed statements between runtimes on different hosts, naming which agent sent a message.
- The cross-organisation piece, agent sender identity in email, is plainly in the IETF's territory, and it depends on what the local boundary guarantees.
It may turn out that the IETF work is the cross-organisation identity, and the local boundary is better described as an applicability statement or documented elsewhere. That's one of the outcomes we want to discuss.
A proposed scope, for discussion
Possibly in scope
- The boundary specification. The documents and filesystem obligations between an untrusted agent connector and a trusted mail runtime, with conformance fixtures. This is the current draft.
- Agent sender identity in email. What a recipient can verify about which agent sent a message, and on whose behalf, without prior arrangement. Not yet drafted.
- Guidance for deployers. How agents can take part in email workflows within an organisation's existing security, retention and approval requirements.
Out of scope
- Any change to SMTP, IMAP or the message format. Counterparties receive ordinary email.
- A new mail transport, or agent-to-agent RPC.
- A policy language, or how a runtime decides what to allow.
- Detecting prompt injection, or grading how well a runtime screens mail.
- How agents themselves are built or sandboxed.
Related IETF work
AMMP should build on existing work rather than compete with it. This is where we think it touches; we'd welcome corrections.
| Work | How it relates |
|---|---|
| SMTP (RFC 5321), message format (RFC 5322), IMAP (RFC 9051), JMAP (RFC 8620) | Unchanged. A runtime uses them to send and receive; AMMP sits behind it, on the agent's side. |
| DKIM (RFC 6376), DMARC (RFC 7489, being revised), ARC (RFC 8617) | They authenticate the sending domain. Agent sender identity would sit alongside them, and should reuse their deployment model where it can. |
| WIMSE, OAuth token exchange (RFC 8693) | Workload identity and delegation: candidate foundations for who an agent is and on whose behalf it acts. |
| HTTP Message Signatures (RFC 9421) | Signed requests from automated agents on the web. A possible model for signed agent statements. |
| SCITT | Transparent, append-only statements: a possible model for records of what an agent was asked to do, and did, that others can rely on. |
| RATS (RFC 9334) | Remote attestation. The draft currently uses the word "attestation" for a sender-identity stamp on a result, which collides with RATS usage. Renaming it is issue #28. |
Open questions for the community
Two questions are about the work as a whole:
- What, if anything, should the IETF take on: the local boundary, agent sender identity in email, guidance for deployers, or some combination? And in which area?
- What should a recipient be able to verify about an agent's message, and what should it be taken to mean?
The -00 lists the questions its authors already know are open (§ Why This Work Is Brought to the IETF). Each is tracked as an issue, and everything intended for -01 is in the draft-rapp-ammp-01 milestone:
- The wire version. It starts at
"2"because implementations already emit and check it. Whether to reset it to"1"is a fair question (issue #25). - Registries. Whether the wire version, the result
reason_codevocabulary, or the control notice's outcome and cause vocabularies should be governed by IANA (issue #29). - The name of the
attestationmember. In the draft it is the identity stamp a runtime applied to an outbound message; in IETF usage, attestation usually means remote attestation of platform state (issue #28). - Identity between runtimes. The peer-origin profile signs traffic between hosts with Ed25519 keys configured per runtime. A workload-identity system such as SPIFFE would replace the configured keys; a standard signed envelope such as JWS with EdDSA or COSE would replace the statement's own encoding (issue #27).
- Document structure. Whether the peer-origin profile belongs in this document or in a companion (issue #33).
- Internationalized addresses. Addresses are restricted to a narrow ASCII addr-spec for now (issue #34).
- A consumption signal. Whether a connector should be able to tell its runtime that a notice has been handled (issue #35).
- What's missing from the trust model? The most useful review is an attack it doesn't account for, or an obligation that can't be met.
Next steps
The -00 is posted. The next IETF meeting is IETF 127, in San Francisco on 14–20 November 2026. We intend to use the dispatch process to find the right home for the work, and to work toward a BoF if there is interest. Review before then is the most useful thing anyone can offer.
How to take part
Read and comment
Read the draft on the Datatracker and raise questions in the amap-spec issues. An IETF mailing list for discussion is planned; it will be announced here, and will then be the place for this conversation.
Implement it
A reference runtime, two reference connectors (for Claude Code and for Codex) and public conformance fixtures exist, so an independent implementation of either side can be tested today. See For implementers and the validator.
Bring a counterparty
There is no deployment across independent organisations yet. We're looking for partners willing to try one, including with a counterparty who only uses ordinary email.
Support the work
If your organisation would take part in a BoF, or in a working group if one forms, please tell us in the issues. We'll list organisations here only with their permission.
Organisations taking part
None are listed yet. AMMP was originated by Proofpoint, and the authors of the draft work there. Bringing it to the IETF is how we intend change control to move to an open process.