For the IETF community
AMAP 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. AMAP is an early individual Internet-Draft 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 The draft is an early individual submission. It has not yet been submitted; once it is, it will be listed on the IETF Datatracker. It reflects one team's thinking and one reference implementation of each side, 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. AMAP 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. AMAP doesn't solve it; it identifies it.
The question we expect first
"AMAP 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 companion peer 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
AMAP 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; AMAP 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. We expect to rename it. |
Open questions for the community
- 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?
- Which values should IANA register? The draft has several open vocabularies, such as result reason codes, attachment dispositions and provenance labels, that are natural registry candidates.
- Should the wire version start again at 1 if the work is adopted? The draft's version reflects work before it reached the IETF, not a claim that the design is settled.
- 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.
How to take part
Read and comment
Read the draft 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, a reference connector 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. AMAP 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.