Identity and accountability
AMAP can verify the sender. The ecosystem must define the agent.
Agent identity and accountability have to come from outside AMAP, and AMAP has to fit whatever emerges. The specification carries identity but deliberately doesn't define it: its scope puts "how identity is minted, how senders are verified" out of scope. "The wire fixes the vocabulary; it never fixes the computation."
From left to right: verifying which agent sent a message → establishing who that agent is and what it may commit to.
AMAP does today
Specified
- The runtime owns each agent's sending identity, and the agent can't choose it (§ Architecture; § Submit Request).
- Configured peer runtimes exchange signed statements, which the sending runtime signs with Ed25519, naming which of its agents sent a message. The keys belong to runtimes, not agents. A message that fails verification is treated as ordinary mail (peer profile §5).
- A record of each request, verdict and policy path, in an audit log the agent cannot write.
AMAP's whitespace
Could extend
- Sender verification any recipient can check without prior setup: "DKIM for agents".
- What a
verifiableattestation should prove to someone outside the fleet. Results already carry an attestation slot whose form can beself-stamporverifiable(§ Result). The name collides with remote attestation in the IETF's RATS work (RFC 9334), and we expect to rename it. - Reputation models for agent senders, akin to those built on authentication signals such as DKIM.
The ecosystem's job
Open
- An identity layer for agents, for example UMA for Agents.
- Who issues an agent's identity.
- What authority that identity carries.
- Who answers for what an agent commits to, and when a person must decide instead.
Why a signature still matters when bad actors can sign too
Hypothesis This is the argument DKIM has always faced. A signature doesn't prove a message is legitimate. What it provides is a verifiable identifier to hang reputation on, and once DKIM was enforced broadly, it became the handle that reputation systems are built on.
The same could hold for agents. If legitimate agent senders adopt verifiable sender identity, bad actors either do the same, and so become identifiable and scorable, or stand out by not doing it. Either way, defenders get a stronger signal for telling good agent traffic from bad. Today's signing works only runtime-to-runtime, between configured peers. Extending it is whitespace, not something AMAP already does.
What authentication proves, and what it doesn't
| Signal | Proves | Does not prove |
|---|---|---|
| SPF, DKIM, DMARC | The sending domain | Which agent sent it, or that it may commit anyone |
| AMAP signed peer statements | Which runtime vouched for which of its agents | That the agent is authorised to commit its organisation |
| An agent identity layer open | Who the agent is, and on whose behalf it acts | Left to the ecosystem to define |
An attestation stamps sender identity. It doesn't mark a message as AI-authored, and it shouldn't be read that way.
Accountability needs a record the agent can't touch
Specified The runtime keeps an audit log that the agent can never write. The specification doesn't define the log's contents, and durability and tamper-evidence are the runtime's responsibility. A production runtime can place agent email under the same communications governance organisations already apply to people's email, with no new regime for agents: retention, supervision and discovery.
Open If the record is to settle who answers for an agent's commitment, what must it contain, and must other organisations be able to trust it?
When must a person decide?
AMAP guarantees that a policy miss goes to a person. It doesn't say which actions should always need one. Should confirming a change to payment details, agreeing contract terms, or opening a new external data flow require a person whatever local policy says? Does the verification bar differ when the counterparty is a government body or a critical-infrastructure operator? These are policy questions as much as engineering ones.
Where should agent identity come from, and what should AMAP accept as proof of it? If you're working on agent identity, we'd like to hear from you. See Get involved.