AMAP Agent Mailbox Access Protocol

Agent Mailbox Access 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. AMAP is an early Internet-Draft 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.

AMAP at the IETF How it works
An agent behind a trusted runtime Inside your organisation, an agent in its sandbox is linked by AMAP 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 AMAP 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 AMAP or not Required change: none
The trusted runtime is the gate on your organisation's edge. AMAP is the link between it and the agent, inside your organisation. Nothing crosses to the other side but ordinary email.

What AMAP 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

AMAP 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

AMAP 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. AMAP 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 AMAP · How it works

Agent-platform builders

Give agents email through a connector with no send capability of its own, behind ordinary MCP tools. For implementers · MCP, A2A and AMAP

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 119 fixtures.
  3. Run the reference implementations. Start with the reference runtime, amap-router-local, and the Claude Code connector, amap-connector-claude.

Status AMAP is an early individual Internet-Draft. It has not yet been submitted to the IETF, 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 AMAP

AMAP 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