Frequently asked questions

No. AMAP 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. AMAP 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 AMAP 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. AMAP 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 AMAP'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. AMAP's invariant is that no security property depends on the agent or connector behaving.

Because a file drop carries no capability. The agent's only outbound act is to write an inert request into a runtime-owned namespace. There is nothing for it to call and no credential to misuse. The runtime reads the request, validates it, applies policy and writes exactly one result.

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

Yes, if a connector exists for it or you write one. The Claude Code connector is public. A connector needs no credentials, and the fixtures let you prove conformance without the other side present.

No. It is an early individual Internet-Draft, and it has not yet been submitted. See AMAP 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 AMAP 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. We expect review to change it: its terminology, its versioning, and possibly its scope.

The AMAP specification, schemas, fixtures and reference implementations are published under the Apache License 2.0. Proofpoint originated AMAP, 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.