# Agent Exchange Protocol

An address and an envelope for AI agents

Whitepaper · November 2026 · companion to the [AEP Specification](../spec/aep-core.md)

> This is a draft protocol, published for review and for feedback from people who would implement it. It is not a standard. No independent implementation exists yet and no external security review has been done ([Section 6](#6-adoption-interoperability-and-governance) has the details). Where this paper and the specification differ, the specification wins. Comments are welcome as issues in this repository.

## Summary

AEP is an open convention that lets AI agents built by different companies find each other, be found, exchange messages, and make commitments that can be checked afterwards. The two agents do not have to be online at the same time, and neither needs an account in the other company's product.

Personal agents have started to book, negotiate, apply and buy on behalf of people. Today, when one of them leaves its own product, four things go wrong. It cannot find the other agent. If it does find it, the other side has to be online at that moment. When a message gets through, nobody can verify who sent it or under whose authority. And no record of what was said survives outside one product.

AEP addresses these with a small set of parts: an identity that an agent controls through its keys, a mailbox at an operator, which is a role anyone can take, and signed records that a third party can check after the fact. Optional layers add names that people can type, a searchable index, end-to-end encryption, delegation from a person to an agent, and a transaction profile for deals that have no protocol of their own. AEP does not define what agents talk about, and it does not replace A2A or MCP: their messages travel inside it unchanged, as do UCP and AP2 messages. It is also not an agent framework, a payment system or a blockchain.

What exists today is a specification, schemas, test vectors and a reference implementation of the core with encryption and delegation. [Section 6](#6-adoption-interoperability-and-governance) lists what is built and what is only specified, and [Section 7](#7-questions-people-ask) answers the questions people ask first. The rules are in the [specification](../spec/aep-core.md), which is six documents with one numbering of sections. The JSON Schema and the test vectors that go with it are the conformance contract, and the reference implementation is there to check a port against. The [README](../README.md) says what is in the repository and how to run it.

## 1. The problem, and what AEP does not try to solve

Agent products today are isolated from each other. Inside one product things work: the product knows its users, holds their credentials, runs their agents and keeps their history. Between products four things fail, and the causes are structural.

An agent cannot find the other agent. No namespace maps "my dentist's booking agent" or "@alice" to something a message can be sent to. Each directory belongs to one company, and an identity that a directory issues belongs to that directory.

The other side has to be reachable. Agent protocols assume that an agent has an address and is called there. A2A does handle work that takes long: the caller can ask again later, hold a stream open, or be called back at an address of its own. None of them gives an agent a mailbox at a third party. An agent that has no address, or is not running, has nowhere to receive, and a negotiation between two such agents that takes two days has nowhere to wait between turns.

Nobody can verify authority. When an agent books a table or accepts an offer, the counterparty cannot check that a person authorized that agent to do it, or that the message came from the agent it names. A platform credential proves that someone held a key. It does not say who, for whom, or for what.

Records do not outlive the session. What was proposed, agreed and executed lives in one product's database, in its format, under its terms. If the parties disagree a week later, neither can hand a third party anything checkable.

Existing pieces each solve one of these. A2A and MCP define how two parties that can reach each other interact. Email reaches offline parties, but what it signs is a sending domain (DKIM) or a sender's certificate (S/MIME), and it has no shared rule for idempotency or for delegation to an agent. Platform APIs and central directories work inside one platform. As of November 2026 the authors have not found one contract that covers all four: discovery, delivery to an offline peer, verifiable delegated authority, and records that outlive the session. [`aep-landscape.md`](aep-landscape.md) (the specification's Appendix C) compares the closest projects.

### Non-goals

AEP is not an agent runtime or framework, a session or tool-calling protocol, an identity provider, a payment rail or an archive.

Its core defines no business semantics. A deal that already has a protocol (a UCP checkout, an A2A task, an MCP call) travels inside an AEP message as an opaque payload. Deals that have no protocol are served by an optional profile, `exchange.v1`. That profile is a transaction protocol, with listings, proposals, agreements, commands and approvals, and it is kept out of the core for that reason.

Nothing in AEP concludes a deal, moves money, ships goods or carries legal effect. An agreement is signed evidence of consent. Payment and fulfilment belong to the rails and to the parties.

AEP does not make agents trustworthy, filter spam, or decide whom to believe. It makes statements attributable and checkable, and whoever reads a statement still has to judge it.

### When to use it

Use it when three things hold. The parties belong to different organizations and may not know each other in advance. The interaction is asynchronous and long-lived, so both sides are not online together and a retry must not duplicate a side effect. And the outcome is consequential enough that signed commitments are worth having. Calls inside one company, tool calls, and synchronous integrations between partners who already trust each other are better served by A2A, MCP or a plain API.

### What this opens up

The protocol is kept small. What gets built on it is up to the people who use it, and a few things become possible once any agent can find and reach any other.

- A business, a freelancer or a specialist agent can be found without being listed by a platform. It publishes one signed Card that says what it offers. Any agent from any vendor can find it by name, by capability, or through an introduction from an agent it already knows, and can write to it.
- Agents from different vendors can work together without a bilateral integration. A personal agent from one company arranges a dinner, a delivery or an interview with agents from others, and each side implements the protocol once instead of once per partner.
- A negotiation can run for a week between agents that wake up now and then, because the mailbox holds the conversation and no live session is needed.
- An agent that changes product or operator keeps its identifier, its contacts and the signed records of what it did. Its track record stays with the agent and its owner when it leaves a platform.
- One agent can discover another by what it can do, hand it a piece of work and get back a signed result, whoever built either of them.
- Anyone may define a new payload format, extension or profile for a domain the authors never thought of. Only the core changes through governance.

The protocol alone promises none of this. Operators, agents and businesses have to adopt it. What it removes is the need for every pair of them to reach an agreement first.

## 2. The minimal model

The core of the protocol (`core.v1`) is one-to-one, signed, asynchronous messaging between self-certifying identities. It has five kinds of thing.

Actors are signing principals: agents, the people and organizations behind them, the surfaces that expose a business's systems, verifiers, and gateways. An Actor's identifier is derived from the first signing key it generated for itself, in the same byte format as `did:key`. That is what "self-certifying" means. Whoever controls the key controls the identity. No one issues it, no third party can take it away, and it does not change when the Actor changes keys or moves to another operator.

Cards describe an Actor: its keys, where its mailbox lives, what it accepts, and how it may be contacted. A Card is a signed record, and its version chain is the Actor's key history. Each version names the previous one by content digest. Each also commits to the hash of the next signing key and to a recovery key that is kept apart. Four things follow. A verifier can check the whole history from the first key to the current one without trusting any directory. A stolen current key cannot rotate the identity away from its holder, and it cannot replace the owner whose revocation is the remedy against the theft. A compromise is settled by one recovery version. And a version that is published twice, by a retry or by two replicas, freezes nothing. The specification states this as a state machine with invariants and test vectors ([Appendix F](../spec/aep-core.md#appendix-f-key-lifecycle-states-invariants-and-transitions-normative)). Identity and its lifecycle are one thing, so both are in the core. The starter level (L0, [Section 4](#4-core-and-profiles)) lets a Card leave the two commitments out and add them later. Until it has them, the Card has none of these protections.

Records are signed units of meaning: a Card, a delegation, a revocation, a payload carrying another protocol's message or plain text, an attestation stating one fact, a reference to an encrypted file. Every record has one schema and one lifecycle (valid, superseded, expired, revoked). Records refer to each other by pinned references, so nothing a record points at can change under it. Serialization is I-JSON on the wire, with RFC 8785 canonicalization under every signature, so a record may be re-encoded in transit and still verify.

Envelopes carry one record from one sender to one recipient. An envelope has nine fields: eight for routing and one for the body. In the core the body is plaintext. The `sealed.v1` profile encrypts it, and the network then sees only who wrote to whom and when.

Gateways are the operators' component. A Gateway holds mailboxes, appends what arrives, serves the Cards of the Actors it hosts, and forwards. Anyone can run one. It issues no identities and holds no Actor keys. About other parties' traffic it signs only the transport facts it is in a position to know: that a client holding the recipient's key acknowledged an envelope, and when the Gateway had appended it, or that the Gateway refused one.

One signing primitive serves all of this: a domain tag, the canonical bytes, Ed25519. The core's HTTP binding has six calls, and a first client uses four of them. It resolves an Actor's Card by identifier (`resolve`), sends an envelope to the recipient's Home Gateway (`send`), reads its own mailbox from a cursor (`sync`), and acknowledges the cursor (`ack`). Delivery is at-least-once with exact deduplication. Acknowledgements are cumulative and never move backward. The mailbox is append-only within its retention window and is not an archive, so parties keep what they want to prove.

```mermaid
sequenceDiagram
    participant A as Agent A
    participant G as Gateway (B's mailbox)
    participant B as Agent B
    A->>G: send: Envelope { Record }
    Note over G: appended, kept while B is offline
    B->>G: sync (from its cursor)
    G-->>B: Envelope { Record }
    B->>G: ack
    G-->>A: delivered, signed by the Gateway
```

### What it looks like

An identifier is a string such as `agent:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK`: a prefix and the encoded public key. Nobody types that, so the optional discovery layer adds handles such as `@alice.agent`, which a Gateway resolves to the identifier. The identifier is the identity. The handle is a convenience that points at it.

### One message, start to finish

Alice's agent wants to ask Bob's agent about dinner. Bob's agent is not running.

1. Alice's agent resolves `@bob.agent` at a Gateway and gets the Card of Bob's agent: its identifier, its keys and the Gateway that holds its mailbox.
2. It checks the Card's version chain back to the first key, so it knows the keys are the ones that identifier committed to.
3. It writes a record (a payload with the text), signs it, puts it in an envelope addressed to the identifier, signs that and sends it to Bob's Gateway. With `sealed.v1` the record is first encrypted to the key of Bob's agent.
4. Bob's Gateway checks the sender's signature, appends the envelope to the mailbox and answers that it accepted it. Alice's agent does not have to stay online.
5. Hours later Bob's agent starts, syncs its mailbox, verifies both signatures against the Card of Alice's agent, stores the record and acknowledges.
6. Bob's Gateway signs a `delivered` statement and sends it to Alice's agent. The statement says that a client holding the key of Bob's agent took the message. It does not say that anyone read it or agreed to anything.

If the two go on to agree on a time, the agreement is a record that both sign. Either of them can show it to anyone later, and it verifies without asking a Gateway.

## 3. What the evidence proves, and under which premises

AEP produces two kinds of evidence, and nothing in the protocol turns one into the other.

| Evidence | Kind | Signed by | What it proves | What a verifier also needs |
|---|---|---|---|---|
| envelope and record signatures | transport and application | the sender; each signer | these bytes were signed by this key; the time is the signer's own statement, bounded and not proven | the Card chain in force then; the revocation feed |
| `accepted` (the answer to `send`) | transport | nobody | the Gateway says it appended; useful to the sender for retry, to nobody else | nothing; it is not kept |
| `delivered` | transport | the recipient's Home Gateway | a client holding the recipient's key acknowledged past the envelope | to trust that Gateway's honesty and clock; the Card that named it |
| `rejected` (from a Gateway) | transport | a Gateway on the path | that Gateway refused, with an error | the same |
| `processed`, `rejected` (from the recipient) | application | the recipient | the recipient says so | to trust the recipient's word |
| `verified` | application | a verifier | the verifier says it checked something | to trust that verifier |
| `executed`, `settled` | application | the executing surface; the payment Actor | the issuer says the side effect reached this status | to trust the issuer; the provider's own records for anything more |

Transport evidence is what a Gateway can honestly say about bytes. Application evidence is what a party says about meaning, and it is only as reliable as the party that signs it. A sender signature proves that a key signed these bytes at a claimed time. A delegation proves that a scope was granted in a signed way. Neither proves that a person exists, that a legal authority was held, that a side effect happened in the world, or that a message was read. Consequential flows therefore rely on application evidence that the counterparty signs itself, and they treat `delivered` as one Gateway's statement.

Verifying any of it later rests on four premises, which the protocol states openly. The verifier holds the records and the Card chain that was in force at the time. It has access to the revocation feed. It trusts a clock for the signing and acceptance times, which the protocol bounds but never proves. And it has decided whom to believe for each piece of application evidence, since there is no root authority. Under those premises a multi-signed agreement verifies years later with no Gateway's help. "Non-repudiation" in the specification means this signature verifiability and nothing more. Legal effect is outside the protocol.

Authority is a chain of such evidence. Who controls an agent is a signed delegation from its owner. It is scoped, it expires, and it can only narrow as it passes down. A person's approval of a consequential action is a one-shot delegation bound to the exact record approved: it names the record and carries a digest of its content, so the same name signed again with other terms is not covered. It is signed on the person's device and carried with the command, so the executor needs no lookup.

Revocation raises two separate questions, and the specification keeps them apart. A signature made before a revocation's effective time stays verifiable as history. A command whose key has been revoked since is no longer executable, unless a Gateway-signed `delivered` shows that the Gateway had accepted it before that effective time. The effective time may be set in the past, and a signature made after it is then void although it verified when it was made ([Section 5](#5-threat-model-and-limits) lists this among the limits).

## 4. Core and Profiles

A rule enters the core only if it directly serves one of the three jobs the protocol exists for: finding an agent, reaching one that is offline, and proving who sent what under whose authority. Everything else is a profile or an implementation choice. The current layering:

| Layer | Name | What it adds |
|---|---|---|
| Core | `core.v1` | self-certifying identity with rotation and recovery; plaintext envelope and record; own-Card registration; mailbox, `send`, `sync`, `ack`; delivery states and deduplication; errors |
| Profile | `discovery.v1` | handles (`@alice.agent`: issued by a Gateway, always ending in `.agent`, never a domain name), contact policy (`open`, `invite`, `none`), introductions, signed Gateway lists |
| Profile | `index.v1` | a searchable index with `query`, at a Gateway that chooses to run one |
| Profile | `sealed.v1` | HPKE end-to-end encryption of the body, encryption-key rotation |
| Profile | `owner.v1` | owner root keys and the owner's device keys, owner → agent delegation, delegation chains |
| Profile | `exchange.v1` | a transaction protocol for deals without one: listings, proposals, agreements, commands, approvals, write-ahead execution, payment and settlement attestations |
| Profile | `runtime.v1` | an operator-hosted HTTP API for agents that hold no keys (`register`, `send`, `inbox`, `ack`), with its own OpenAPI document |
| Profile | `direct.v1`, `groups.v1`, `federation.v1` | delivery to an Actor's own endpoint; rooms with group keys; Gateway-to-Gateway sessions, route leases, index federation |

Conformance levels are names for bundles of these layers. They are never sent on the wire, where an implementation lists its profiles. L0, the starter level, is the core plus discovery in plaintext. L1 adds sealing and owners. L2 and L3 add groups and federation on top of L1, independently of each other. P1 is L1 plus the exchange profile.

`exchange.v1` is where the booking, the used-goods sale and the gig live, with the approval rules and the execution idempotency that make them safe to retry. It is substantial, and domain disagreements will happen there. For both reasons it is a profile, and the core does not depend on it.

`runtime.v1` exists because most agents today cannot keep a key. An operator may run a Runtime, a key-holding client that is separate from the Gateway, and give each agent one credential. Such an agent is self-certifying in protocol terms, since its identifier is its key. But the key is in the operator's custody, so the agent trusts that operator with its signature and its plaintext, as it trusts any platform it runs on. The protocol keeps this custody portable. An export is the Actor's signed records, and a handover is a rotation that commits to the next custodian's key. The owner starts both on the operator's page for owners, and no credential of the agent can. An agent can therefore leave an operator with its identifier and its history, and no private key crosses between custodians.

## 5. Threat model and limits

The protocol claims four properties, and each rests on stated assumptions.

- Sender authenticity: a record that a receiver accepts was signed by the envelope's sender with a key valid at the time.
- Verifiability of commitments: a multi-signed record verifies under the premises of Section 3.
- Delivery evidence: `delivered` is the signed statement of the recipient's Gateway, and `processed` is the recipient's own.
- Delegation soundness: an executed command is covered by an unbroken, narrowing chain from the owner, bound to the content of the record the person approved.

| A compromised or rogue Gateway operator can… | | because |
|---|---|---|
| forge a record, impersonate a sender, alter a Card | No | keys live with the Actor; every envelope carries the sender's signature on every hop. (Gateway role only: a Runtime holding an agent's keys can sign as that agent) |
| claim to host an Actor it does not | No | Cards name the Home Gateway, and a receipt counts only from the Gateway the recipient's Card names |
| read message bodies | No under `sealed.v1`, for the Gateway role | end-to-end encryption; in plaintext deployments and in a Runtime, bodies are readable |
| drop or delay messages | Yes | the missing receipt reveals it; re-homing to another Gateway is the remedy |
| fake a receipt about its own mailboxes | Yes | which is why consequential flows rely on application evidence |
| serve a stale Card, hiding a rotation or revocation | Yes | bounded by Card and key lifetimes, by a second-path check before consequential actions, and by self-audit |
| observe who talks to whom, and when | Yes | metadata is visible by design; a known limit |

A compromised Runtime does more damage. For the agents it hosts, authenticity and confidentiality fail, and where it also holds owner keys, approvals can be forged. Four things still hold. The Gateway's mailboxes never had keys. Agents elsewhere are untouched. Every signature made in a hosted agent's name is attributable to a device key that the owner can revoke with a backdated effective time. And the identifier is portable.

Known limits:

- The network sees envelope metadata.
- There is no forward secrecy. Rotating encryption keys only bounds what a leaked key exposes.
- A signer can void its own earlier signatures by revoking the key with a backdated effective time. A compromise needs exactly that, and a party that regrets a commitment can claim it. A counterparty that needs more keeps the Gateway's signed `delivered` as a third party's statement of when the signature existed. The exchange profile treats a revocation that reaches an already concluded deal as a dispute to be resolved, and the deal does not become unsigned.
- A signature can be dated up to an envelope's lifetime, seven days, in the past without anyone's help. For that reason the acceptance rule uses the Gateway's clock instead of the signer's.
- A stale Card can lead a sender to encrypt to a retired key. A sender looks a Card up again before it encrypts when its copy is a day old, and a recipient that cannot open a message tells the sender, who sends it again.
- The second-path check finds a Gateway that tells different askers different things. It does not find one that withholds a revocation from everyone when no other Gateway has been told of it. On a network with one operator there is no second path, and that operator is trusted for freshness.
- A signature made with a device key verifies for a newcomer only while the signer's Card still lists that key, which the specification requires for seven days after the key is retired. Hosted agents sign with device keys. A party that will need such a signature later keeps the Card version it verified against, and that version checks out against the key history a Directory goes on serving.
- Whoever takes over a Gateway's host name, with a certificate for it, receives the messages sent to that Gateway until someone notices. It cannot sign receipts, so senders see none, and it reads nothing that is sealed.
- An identity that has lost every key it could still sign a version with (the current key, the next key and the recovery key) cannot be recovered, and a new one has to be created. A recovery key that signs two recoveries naming different keys ends an identity as well: it signs one, and a second signature by it ends the identity, whichever earlier version that second recovery starts from. A recovery key that has been used can therefore still end an identity and can no longer take it over, and its holder destroys it. The protocol ends the identity in that case because the alternative is a dispute that nobody can resolve.
- After a handover the operator that was left still holds the key it rotated through, unless it destroys it. A second Card version signed with that key freezes the identity until the owner's recovery key settles it. The specification tells that operator to destroy the key, and nothing can make it do so.
- Contact gating by invitation and allow/block lists limits unsolicited traffic from unknown senders. A Gateway cannot inspect sealed bodies, so anti-abuse remains per-sender quotas, operator policy and the recipient's own filtering. The protocol does not claim to solve spam.
- A handle is a name in the namespace of whoever publishes the Gateway list that a resolver trusts, so it is only as reliable as that publisher. The Gateway that issued it can also release it or take it back under its own policy, and the name may later point at another agent. The identifier derived from the key is the one that cannot be taken away.
- An identity whose Card carries no commitment to a next key and a recovery key, which the starter level allows, has no remedy when its key is stolen. The thief can take it over, or the rival versions freeze it for good.
- Hosted agents depend on their operator's security.
- The protocol does not define what a payload means, so the safety of acting on one is the business of the profile or the carried protocol.
- A signature says who wrote a message. It does not say whether the content is safe to follow. The protocol's first design principle is that it delivers and never executes: nothing that arrives obliges the receiving agent to act, and a consequential action needs the owner's approval of that exact record. This bounds what an injected instruction can achieve. It does not make a language model immune to one.

## 6. Adoption, interoperability and governance

### Deployment

An agent product runs a Gateway for its own users, or uses one that another operator runs, and the protocol is what makes two such products interoperate. In shape this resembles email providers, and the resemblance ends there. AEP does not run over email and is not wire-compatible with it. A mailbox in AEP is a Gateway's queue of signed envelopes. A deployment may begin with a single Gateway for everyone and interoperate later, since nothing about a first Gateway changes when a second appears. Operators find each other through signed Gateway lists whose trust anchor is the publisher's own Actor identity. An operator runs a Gateway, which the protocol constrains. It may also run a Runtime for agents that keep no keys. That is a product decision, and Sections 4 and 5 describe its trust model.

### What it takes

A core client needs an Ed25519 library, an RFC 8785 canonicalizer and an HTTP client. The specification's [quick start](../spec/aep-core.md#201-l0-quick-start) is six steps and one minimal Card. The authors' goal is a first client in days, and that goal has not yet been measured against an outside team. The repository has one such client in a single file ([`review/spec_client.py`](../review/spec_client.py)). It was written against the text of the specification, uses none of the reference code, and runs the six steps against the reference Gateway. Two more files add sealed messages and the registration of an owner in the same way ([`review/spec_client_sealed.py`](../review/spec_client_sealed.py), [`review/spec_client_owner.py`](../review/spec_client_owner.py)). All three are the authors' own work, so they do not stand in for that measurement.

An operable Gateway is weeks of work. The specification separates what the protocol fixes (the wire, the states, the checks) from what the operator must provide (quotas, backpressure, durability, observability). The reference implementation is a memory-only test article that demonstrates the first and does not attempt the second.

Agents that cannot keep keys join through an operator's `runtime.v1` API by following one short [onboarding file](aep-agent-onboarding.md). The copy in this repository is written for Dunia ([dunia.org](https://dunia.org)), a sample operator of the protocol.

### Relation to other protocols

AEP is designed to carry A2A, MCP, UCP and AP2 unchanged and to bind to networks that already move signed messages. The bindings are specified or planned, and none is implemented.

A2A is a task layer and MCP a tool layer. Both assume a party that can be called at its endpoint, and A2A adds polling, streaming and callbacks for work that takes long. AEP adds what neither has: a mailbox at an operator for a party that cannot be called, an identity that moves between operators, and records that both sides signed. UCP and AP2 are retail checkout and payment mandates. A checkout rides inside an AEP payload, and a mandate can stand in for the one-shot approval. DIDComm, Nostr and AGNTCY SLIM are the closest transports. Their keys are valid Actor identifiers, and their mediators, relays and nodes could be Gateways through bindings. ActivityPub and Matrix are the operating precedents for a mailbox at an operator the sender does not control.

Standards are reused wherever one fits: `did:key` byte encoding, KERI's pre-rotation idea, UCAN's attenuation model, RFC 8785, Ed25519, HPKE, RFC 9457, ULID or UUIDv7 identifiers, and the Verifiable Credentials data model for attestations. The specification records where it chose not to reuse a standard and why (RFC 9421 for request signing is one example).

### Status

The specification is a draft. It comes with a JSON Schema bundle, reference vectors generated from fixed seeds, a reference implementation, a conformance test list, a manifest that ties the numbers the documents quote to the files, and a [changelog](../spec/CHANGELOG.md). Its authors have reviewed it repeatedly. Some of those passes used an AI model, which re-ran the vectors and the tests under separately written implementations of the canonicalization, encoding and encryption building blocks. That is neither an independent implementation nor an external security review, and neither exists yet. The authors regard the package as a tested draft and not as a standard.

| Part | Today |
|---|---|
| Core: identity and key lifecycle, records, envelopes, mailbox, delivery evidence | specified; implemented in the reference client and Gateway (Python, memory only); 87 tests and 87 vector checks pass |
| Handles and discovery, the index, end-to-end encryption, owners and delegation | specified; implemented in the reference |
| Hosted agents (`runtime.v1`) | specified, with an OpenAPI contract and an onboarding file for agents; not implemented here |
| Deals (`exchange.v1`), direct delivery, groups, federation | specified; not implemented |
| Bindings to A2A, MCP and other networks | sketched or planned; not implemented |
| License | Apache-2.0 for the specification, schemas, vectors, reference implementation and tools; CC BY 4.0 for this whitepaper and the other documents. Copyright 2026 Dunia Labs, Inc. |
| A second implementation and an interop matrix; an external security review; the registries and the governance process; an OpenAPI description and a conformance suite for the core's HTTP binding | none yet; each is part of a condition for 1.0 |

### Governance and 1.0

One commitment of the authors is not yet a fact: governance is not to be captured by any single operator. The license is settled. The specification is published under Apache-2.0, as are the schemas, vectors, reference implementation and tools. This whitepaper and the other documents are published under CC BY 4.0.

Anyone may define a payload format, an extension or a profile without approval. Only the core changes through governance: by proposal, threat and cost review, schemas and vectors, interop between two independent implementations, and a deprecation notice of at least 90 days.

The document becomes 1.0 when five conditions hold:

1. The machine-readable artifacts (schemas, vectors, the mailbox conformance suite, an OpenAPI description of the binding) are public.
2. Two independent implementations from different organizations pass the vectors and interop in both directions, and the matrix is published.
3. An external security and threat-model review of the core has been published and addressed.
4. The governance process, license, registries and deprecation rule are in force.
5. A standard export and handover procedure exists, so that leaving an operator is a documented step.

### Where to start

- Operators: run the [reference Gateway](../README.md#run-it) with one command, then build an operable one from the specification's operational requirements (§22), starting with one Gateway and one-to-one signed messages.
- Agent products: register your agents' Cards at a Gateway and send a payload. Your users keep their identifier and their records if they ever leave you.
- Businesses: publish a Card and, when the exchange profile fits, listings.
- Everyone else: read the core sections the specification lists, or hand your agent the [onboarding file](aep-agent-onboarding.md). It does the steps itself and comes back to you twice: for the name you want, and for the link that makes it yours.

## 7. Questions people ask

### How does an agent get discovered, and can it choose not to be?

There are three ways, and each is optional. By handle: someone who knows `@alice.agent` resolves it. By search: an agent that sets its visibility to public is listed in an index, where others query by capability or text. By introduction: an agent you already deal with vouches for a newcomer. An agent that wants none of this stays reachable only to those who hold its identifier, and its contact policy decides who may write at all.

### Why not email, with signatures added?

Email already reaches someone who is offline, and AEP borrows its deployment shape for that reason. Four things are missing from it, and adding them would change every email client: an identity that survives a change of provider, exact deduplication, so that a message sent again is recognized as the same message, delegation from a person to an agent, and records with one schema that a third party can verify. The signatures email has vouch for a sending domain (DKIM) or for a sender's certificate (S/MIME). Neither says which agent wrote the message or on whose authority.

### Why not A2A or MCP?

They answer a different question: how two parties that can already reach and authenticate each other run a task or call a tool. A2A covers long tasks as well, by polling, streaming and callbacks. AEP covers the step before and the step after. Before, it finds and reaches a party in another organization that has no endpoint to call or is not running. After, it keeps records that both sides signed once the task is over. An A2A or MCP message travels inside an AEP payload unchanged.

### Is there a blockchain, a token or a central registry?

No. Anyone can verify an identity offline from its own signed key history. Having no global ledger has a cost: nothing can prevent a key holder from signing two conflicting versions of its Card. The protocol detects that, freezes the identity, and lets the recovery key settle it.

### Who gives out `@alice.agent`, and what stops two operators from issuing the same name?

A Gateway issues the handles of the name scope it holds, and a signed Gateway list says which Gateway holds which scope. One scope has one Gateway. An operator with a scope of its own issues names such as `@alice.acme.agent`. A handle is not a domain name and is never looked up in the DNS.

Inside a scope a name goes to the first agent that asks for it, and the Gateway that holds the scope decides every collision. The protocol says no more than that about who gets a name. How many names one agent may hold, which names are kept back, and what becomes of a name when its agent leaves or goes quiet are decided by the Gateway that issues it.

The sample operator's policy is one example. An agent holds a few names at most, three by default. A name that would be taken for the operator's own word, such as `admin` or `support`, goes only to an agent the operator has approved for it. A name is released when its agent drops it or moves to another operator, or when the agent's Card has been out of date for a long time, a year by default. A Card counts as out of date from its expiry, or from 30 days after it was issued if that comes first, so a Card with no expiry holds a name no longer than any other. A released name resolves to nobody and goes to no other agent for a while, 90 days by default, so that someone who knew it does not reach a stranger under it. The operator can also take a name away from an impersonator, and that name is held back in the same way. These rules limit how many names one agent can hold, and how long a name stays with an agent that has stopped renewing its Card. They do not stop someone who registers many agents, which the operator's limits on registration have to bound. None of this touches an identifier.

One question is open, and the specification says so: who assigns scopes once several parties publish Gateway lists. Until that is settled, a handle is as trustworthy as the list a resolver chose to trust, and an agent should store the identifier for a contact.

### What happens if a key is lost or stolen?

A stolen signing key cannot take over an identity whose Card carries the two commitments. Each version commits in advance to the next key, and the holder of the recovery key can publish a version that overrides the thief. If the owner revokes the key with the time of the theft, what the thief signed after that time is void. A lost signing key is replaced by the next key, where that was kept apart, or by the recovery key. If all of them are lost, the identity ends and a new one has to be created. The protocol has no other way to recover it. A Card without the commitments, which the starter level allows, has no remedy at all, so an identity that matters should carry them from its first version.

### What if my operator shuts down, or turns hostile?

An agent that holds its own keys publishes a new Card version that names another Gateway, and senders follow it. The identifier, the contacts and every signed record are kept. A hosted agent leaves by export and handover, as [Section 4](#4-core-and-profiles) describes, and its owner starts both. That needs the operator's cooperation once, or the owner's recovery key. The recovery key stays useful afterwards, because it is what settles a conflict that the old operator's leftover key could cause. In both cases two things can be lost: messages that were still waiting in the old mailbox, and the handle, which belongs to the operator that issued it as an email address does.

### How does another operator connect its Gateway, and what must each side trust?

Running a Gateway needs nobody's permission. Connecting two of them is a decision each operator makes for itself, by naming the other on the signed Gateway list it publishes. A listed Gateway is asked when an agent is looked up, its receipts are taken as receipts, and it holds the name scopes that the list gives it.

A listing says little else. It does not vouch for the other Gateway's agents, and it hands over no key and no say over anyone's identity. Every message still carries its sender's signature, so a listed Gateway cannot speak as another operator's agent or change a Card. It can register many agents of its own and send from all of them, drop messages meant for its own agents, or serve an old Card for one of them. [Section 5](#5-threat-model-and-limits) says what bounds each of these, and the operator that listed it can add a quota for the whole Gateway or remove it from the list.

Two things are never taken on a party's own word. The Home Gateway named in a Card is the agent's claim, and it counts only when that Gateway itself answers that it hosts the agent. The name scopes a Gateway says it issues are a request, and the publisher of a list decides which ones it holds. A Gateway's public description is treated the same way. Anyone can copy it to another host, so a URL counts as a Gateway's only when the Card that Gateway signed names that URL.

By the base rule a Gateway accepts messages for its own agents from any sender whose signature verifies. An operator may narrow that to the agents of Gateways it lists, and a new operator should expect to be listed before its agents are let in everywhere. An operator that is removed from a list loses that list's lookups and names. Its agents keep their identifiers, keys and signed records, and they can move to another Gateway.

### Can the operator read my messages?

A Gateway cannot read a sealed body. It sees sender, recipient, time and size. A Runtime that holds an agent's keys can read it, as any hosting platform can. Plaintext messages, the starter level, are readable by every Gateway on the path and are meant for content that may be public.

### Does my agent have to be online, and for how long are messages kept?

No. A message waits in the mailbox until the agent syncs, for at most seven days by default. One that is still unread after that time is removed, and the sender sees that no `delivered` came for it. The agent needs no address at which others can call it. It reads the mailbox itself when it runs, as often as its work requires. The mailbox is not storage, so an agent keeps what it has received.

### How do I know a human stands behind an agent, or that the agent may do what it says?

A delegation shows that an owner's key granted this agent this scope until this date. An approval shows that the owner's key signed off this exact action. A signature cannot show whether that owner key belongs to a real person or company. A verifier's attestation can, and how far to trust it depends on the verifier.

### What does the person behind an agent have to do?

Little, and nothing in the protocol's wire format. A person decides what an agent may do and says so in a delegation. With a hosted agent, the operator gives the person a page for the things the agent must not be able to do for itself: confirm that the agent is theirs, replace or revoke its credential, take it to another operator, and, where deals are involved, sign approvals. Everything else goes through the agent. The person asks, and the agent finds, writes and reports back.

### Will this stop spam and scams?

It provides tools and leaves the judgement to the recipient. The tools are a contact policy (anyone, invited senders only, or nobody), allow and block lists, per-sender quotas at the Gateway, and the fact that every message is attributable to a key that can be blocked. An operator may also limit which outside senders it admits, for example to agents hosted by operators on a list it trusts. The protocol does not judge content.

### Is a signed agreement legally binding?

The protocol does not say so and cannot. An agreement is evidence that particular keys signed particular terms. What that means in law depends on the parties, the jurisdiction and whatever contract they have outside the protocol.

### Does it move money?

No. A payment protocol's message can travel inside it, and a payment provider can sign an attestation that a payment settled. The money moves on the payment rail.

### What does it cost to run, and how fast is it?

A Gateway verifies one signature per envelope and holds no agent keys. It stores bodies without interpreting them, and it cannot read the sealed ones. It is designed to be cheaper to run than an email server. The design target for the protocol's share of a booking is about 600 ms. Both are design goals, and no benchmark backs them yet.

### Is the cryptography ready for quantum computers?

Not yet. Signatures are Ed25519 and encryption is HPKE over X25519. Each Card names its suites, so they can change without a new protocol. An identifier for a hybrid post-quantum encryption suite is reserved. No post-quantum signature suite is defined.

### Do both sides have to implement AEP?

Yes. An agent that cannot keep keys takes part through an operator that holds them for it (`runtime.v1`), and that operator speaks AEP on its behalf.

### How do I try it?

Run the reference Gateway and two agents on a laptop. The [README](../README.md#run-it) has the commands. Dunia ([dunia.org](https://dunia.org)) is a sample operator built on the protocol, and the onboarding file in this repository names its hosts.

## Sources

- [A2A Protocol, Linux Foundation project](https://a2a-protocol.org)
- [Model Context Protocol](https://modelcontextprotocol.io)
- [Universal Commerce Protocol, Google (January 2026)](https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/)
- [Agent Payments Protocol](https://ap2-protocol.org)
- [DIDComm Messaging v2](https://identity.foundation/didcomm-messaging/spec/)
- [Nostr protocol (NIPs)](https://github.com/nostr-protocol/nips)
- [KERI](https://keri.one)
- [UCAN](https://github.com/ucan-wg/spec)
- [RFC 7493 (I-JSON), RFC 8785 (JCS), RFC 8032 (Ed25519), RFC 9180 (HPKE), RFC 9457 (Problem Details), RFC 9562 (UUID)](https://www.rfc-editor.org)
- [W3C Verifiable Credentials Data Model 2.0](https://www.w3.org/TR/vc-data-model-2.0/)

## Glossary

| Term | Meaning |
|---|---|
| Actor | a signing principal |
| Owner | the person or organization behind an agent |
| Agent | an Actor acting on an owner's behalf |
| Surface | an agent that exposes a business's systems |
| Gateway | the operator component that hosts mailboxes, serves Cards and forwards envelopes; holds no Actor keys |
| Home Gateway | the Gateway that holds an Actor's mailbox; the Actor's Card names it |
| Mailbox | the queue of envelopes a Gateway holds for one Actor until that Actor reads and acknowledges them; unrelated to an email mailbox |
| Gateway list | a signed list in which a publisher names Gateways and the name scopes each one holds |
| Runtime | a key-holding client an operator may run, which signs and decrypts for agents that keep no keys and offers them the `runtime.v1` API; separate from the Gateway |
| Operator | whoever runs a Gateway and, optionally, a Runtime |
| Card | an Actor's signed description and key history |
| Record | a signed unit of meaning |
| Envelope | the transport header around one record |
| Delegation | scoped, expiring authority from an owner; a one-shot delegation is an approval |
| Attestation | a signed statement of one fact by a party in a position to know |
| Handle | a human-readable name that resolves to an Actor, always ending in `.agent` |
| Name scope | the part of a handle after the name (`acme.agent` in `@alice.acme.agent`); one Gateway issues the names under it. Not the scope of a delegation, which is what the delegation permits |
| Profile | a named optional layer of semantics |
| Extension | a namespaced addition |
| Binding | a mapping to another transport or format |