AGENT TRUST PROTOCOL
ARIA gives agents identity.
ATP is what happens at the door.
When an AI agent arrives at your API, three things need to happen: identity is verified, intent is declared, and authorization is checked against your policy. That is ATP.
This page explains it. The normative reference — parameters, result codes, the grammar — lives in section 8 of the specification, and nothing here repeats those tables.
The agent presents its AID — a signed W3C Verifiable Credential — and a signed Intent Declaration: what it wants to do, on whose behalf, within what limits.
Your system checks both against the admission policy you configured — the same one you publish in DNS so agents can read it in advance.
Pass or refuse, with a result code and a literal reason.
WHAT IT LOOKS LIKE
A purchasing agent arrives at a supplier's ordering API. It declares its credential and its intent: place a purchase order, on behalf of its principal, within a scope it names. The supplier's system resolves the credential, checks that the agent is still active, that its level meets the supplier's minimum, that the scopes it asks for are ones the supplier admits — and admits it, or tells it precisely why not. No call to the registry at decision time; everything the receiver needs is local once the credential and the status list are fetched.
Zero coordination. The agent never needs the receiver's policy record to exist; the receiver never needs the agent's anchor record. When one organization plays both roles the two records coexist under its domain, because they have different names.
DECLARE
The agent presents its AID — a signed W3C Verifiable Credential — and a signed Intent Declaration: what it wants to do, on whose behalf, within what limits.
WHAT THE AGENT PRESENTS
ATP evaluates an authenticated presentation, not a document someone pasted. Four things arrive together, and the first two are checked before the credential is even parsed (§7, steps 2 and 3).
The agent's DID
Which identity is claiming to act. Resolved to the AID that was signed for it.
The audience
Whom this presentation was made for: you. A presentation built for another receiver is refused with 421, which is what stops one from being replayed against you.
A fresh proof of possession
Evidence that the caller holds the agent's holder key right now, over a nonce or counter. Without it a credential proves who it belongs to, never who is calling.
The signed Intent Declaration
What the agent means to do, on whose behalf, within what limits — signed by the same key.
The wire binding is not published. How this material travels — HTTP headers, MCP metadata — and which suite secures the ephemeral presentation is protocol decision D7, still open. Until it is decided there is no conforming ATP transport. If you are building today: do not invent a header that carries a bare AID and treat it as a presentation. An AID is a public document; anyone can fetch a competitor's and replay it.
Track it: presentation binding →INTENT DECLARATION. NOT OPTIONAL.
Before an agent is admitted it states its purpose — what it intends to do, for whom, within what boundaries — and signs it. An Intent Declaration must be present for the handshake to proceed at all; three fields are the protocol minimum, and your policy can require more. The principal is named by DID, never by a person's name.
Fields and requirement levels: specification §8, Intent Declaration table →EVALUATE
Your system checks both against the admission policy you configured — the same one you publish in DNS so agents can read it in advance. Level sufficient? Scopes covered? Status fresh? Delegation within depth?
PUBLISH YOUR POLICY. ONE DNS RECORD.
Receivers publish an Agent Trust Policy as a TXT record at _aria-policy.<host>. Agents look it up host first, then apex. It tells them what you require before they knock.
- Open your DNS panel and add a TXT record at _aria-policy under the host that serves the API (or the apex, for every host).
- Start with enforce=monitor. Nothing is blocked; you see who arrives.
- Set min= to the lowest level you accept. L0 admits any agent with a valid credential; L2 requires a confirmed legal entity behind it.
- Add fresh= if your risk tolerance is tighter than the default hour; the floor is 60 seconds.
- Point rua= at a mailbox or endpoint for aggregate reports.
- Configure the same policy in your evaluator. The configured policy decides; the DNS record informs — they must match.
EXAMPLE: FINANCIAL SERVICES
_aria-policy.bank.com TXT v=ATP1; min=L2; enforce=strict; req=commerce:order:*,finance:invoice:read; deny=identity:principal:*; intent=purpose,principal_ref; depth=3; fresh=300s; rua=https://bank.com/atp-reports
Scopes have three colon-separated segments with a wildcard only in the last. Every parameter, its class and its default: specification §8, Agent Trust Policy table.
THE ELEVEN CHECKS
Order is the design.
Cheapest and most local first, state-dependent last, and the first failure ends it with its own code. This is not a preference: a receiver that checked scopes before the signature would be reasoning about a document it never authenticated.
Reached only when your status evidence has aged past fresh=. Stale and unrenewable is a refusal, not a pass.
First failure wins. Every denial carries exactly one code and one literal reason — the step that failed, the values compared, and the record consulted. A decision you cannot explain is not conforming.
enforce does not change what is checked. All eleven steps run in every mode and the result is always recorded. Strict denies. Warn admits and flags. Monitor admits silently. No mode admits a failure of integrity, presentation or audience.
THREE LAYERS. THEY ADD UP.
Not three options to choose between. Every admission runs on the first layer alone. The second is reached only when your status evidence has aged past fresh=. The third never takes part in an admission at all.
Central reaffirmation must not sit in the admission path (ATP-09). A default SDK resolver does not call it while evaluating. Routing per-call queries through the authority would build a single point of failure for the ecosystem, and the most sensitive metadata log in it: who asks about whom. Freshness is answered by the issuing registry's aggregate list, which does not identify the agent being checked.
Normative: specification §8, deployment layers →ADMIT
Pass or refuse, with a result code and a literal reason. What happens next follows the mode you set: monitor, warn, or strict.
START WITH MONITORING. ENFORCE WHEN READY.
ATP is designed for progressive deployment, the way DMARC was. Monitor logs everything and admits everyone. Warn admits but marks non-compliant agents so your API can treat them differently. Strict refuses. Move up when you understand your traffic.
Every check runs, nothing is blocked, everything is logged. This is where you start and where you learn who actually calls you.
Admitted, but flagged: the response carries ATP-200 with the code that would have denied, so your API can treat that caller differently.
A failure denies, with one code and one literal reason. Move here when your logs stop surprising you.
WHAT RUNS TODAY
Publishing your policy record works now, and it is useful on its own: it tells agents what you require before they knock, and it is how the ecosystem learns your requirements. Evaluating a presentation does not work yet, because admission needs the holder proof and the challenge endpoint is not enabled. Verification — knowing which agent a credential belongs to — works today with the SDK.
What is live, what is planned →THE DMARC PARALLEL
If you understand DMARC, you understand ATP. Same pattern, same progressive deployment, one addition: intent.
DMARC authenticates who sent an email. ATP authenticates who the agent is and evaluates what it intends to do.
Publish your policy. Today.
One DNS record in monitor mode tells every agent what you require, and costs you nothing to change later. It is the part of ATP a third party can deploy without asking anyone — and the part that will still be correct when admission ships.
YOUR FIRST ATP POLICY
_aria-policy.yourdomain.com TXT "v=ATP1; min=L0; enforce=monitor; rua=mailto:you@yourdomain.com"
ATP is specified normatively in §8 of the ARIA specification. The full ATP/1 document — algorithm, conformance vectors, SDK requirements — is planned as a standalone publication.