Agent Mediated Messaging Protocol

Agents are joining the workflows that run on email.

Email is the backbone of how organisations work together, and agents will need to take part in it. AMMP is an individual Internet-Draft, posted to the IETF Datatracker in October 2026, that proposes how: an agent can read, draft and ask to send, while the credentials, the sending identity and the decision about who receives anything stay outside the agent. We're bringing it to the IETF for review, and to find collaborators.

An agent behind a trusted runtime Inside your organisation, an agent in its sandbox is linked by AMMP to a trusted runtime. The runtime is the gate on the organisation's edge, and ordinary email flows between it and any other organisation. YOUR ORGANISATION Agent in its sandbox AMMP TRUSTED RUNTIME your policy, your people email ordinary email, nothing added ANY OTHER ORGANISATION A person with an inbox A person with an assistant Their own agent, with AMMP or not Required change: none
The trusted runtime is the gate on your organisation's edge. AMMP is the link between it and the agent, inside your organisation. Nothing crosses to the other side but ordinary email.

What AMMP proposes

Containment, not trust

Assume the agent will sometimes be fooled. It holds no mail credentials and can't choose its sending identity. Its only outbound act is a request.

A person on a policy miss

The runtime checks every recipient against the organisation's policy. When a request falls outside it, a person decides. Nothing is sent or dropped silently.

One side can start today

AMMP adds nothing to the mail between organisations. Counterparties keep using email exactly as they do now.

Open and checkable

An open specification with public conformance fixtures, so anyone can test any implementation against the same rules.

Who we'd like to hear from

Standards and identity communities

AMMP can verify which agent sent a message within a deployment. Who that agent is, what it may commit to, and how a recipient elsewhere can check, has to come from the wider ecosystem. AMMP at the IETF · Identity and open questions

Security and governance teams

See what the design guarantees, what it leaves to local policy, and what it doesn't cover. Why AMMP · How it works

Agent-platform builders

Give agents email through a connector with no send capability of its own, behind ordinary MCP tools. Two exist, for Claude Code and for Codex. For implementers · MCP, A2A and AMMP

Runtime and mail-infrastructure implementers

Build a trusted runtime that holds the credentials and enforces the policy, and prove it against the fixtures. The specification · Validator

Getting started

  1. Understand the model. Read how it works: three zones, a sandboxed agent, and a trusted runtime that decides.
  2. Check documents against the specification. Try the in-browser validator, or run the conformance gate yourself with python3 fixtures/validate.py from the amap-spec repository. It uses only the standard library, needs no network, and runs 121 fixtures.
  3. Run the reference implementations. Start with the reference runtime, amap-router-local, and a connector: amap-connector-claude for Claude Code, or amap-connector-codex for Codex.

Status AMMP 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. There is no deployment across independent organisations yet, and we're looking for reviewers, implementers and interop partners. Full status

Who is behind AMMP

AMMP was originated by Proofpoint and is published as an open specification under the Apache License 2.0. The specification, its schemas and fixtures, and the reference implementations are public, and no one needs a particular vendor's runtime to conform or to interoperate. We're bringing it to the IETF so that its future is decided in an open process, not by its originator. Get involved

Until October 2026 the protocol was called AMAP, the Agent Mailbox Access Protocol. It was renamed before its first submission because "mailbox access" named only its first channel: the contract mediates an agent's correspondence, mail and peer traffic alike. Nothing on the wire changed. The repositories keep their amap- names, and the two header fields the peer-origin profile defines keep theirs.