Reference architecture
The Chain of Trust for AI Agents
An open reference architecture that connects existing internet standards into one verifiable chain for discovering, identifying and authenticating AI agents. A business can check an agent at every step, from discovery to payment to audit, without relying on any one platform’s word for it.
Demonstrated by GoDaddy, Infoblox, Google and Cloudflare in collaboration with Singapore’s Infocomm Media Development Authority (IMDA), based on IMDA’s Model AI Governance Framework for Agentic AI (v1.5). Open Agent Commerce publishes the architecture, the demonstration and the hands-on labs.
The problem
Today an agent vouches for itself
Before a counterparty lets an agent act, it needs to know three things: who are you, who authorised you, and can anyone prove what you did afterwards. Today every answer comes from the agent or its operator: the agent card, the tool listing, the catalogue, the model card, the activity log. And most of the systems that decide whether to trust an agent are closed, so a trust decision made on one platform doesn’t carry over to the next.
Seven layers
Each layer relies on an open standard
The layers are independent, so a weakness in one does not silently compromise the others. Every layer has more than one open option, and none of them requires a single gatekeeper. The right-hand column is where each layer shows up in the eleven-step flow.
| Layer | Question it answers | Standards | In the demonstration |
|---|---|---|---|
| Discovery | Which agents exist, and where do they run? ARD for resource and capability discovery, and DNS-AID for DNS-based lookup, to find which agents exist and where they run. | ARD, DNS-AID | Step 2: the buyer finds the seller in signed DNS, starting from the domain alone. |
| Identity | Is this agent who it says it is, and can anyone check? A registered identity that anyone can verify from public evidence, not just a certificate the agent presents in a single session: ANS, alongside SPIFFE for the identity of each running instance. | ANS, SPIFFE, DNSSEC, DANE | Step 3: the buyer’s fourteen checks on the seller, one of them its registration in the ANS public log. |
| Authorization | Who controls the agent, and what may it do? Establishes who controls an agent and what it may do. | OAuth, passkeys | Step 1: the person’s assistant calls the buyer with an access token the approval service issued after a passkey sign-in. |
| Communication | How do agents reach tools and each other? Allows agents to reach tools and each other. | A2A, MCP | Steps 1 and 4: the assistant reaches the buyer over MCP; the buyer reads the seller’s A2A agent card. |
| Payment | Did a person approve this purchase, within what limits? Carries the person’s signed authorization and the agent’s identity into the checkout. A person sets what an agent may buy and how much it can spend in a signed AP2 mandate, and merchants and payment providers can check every purchase against it. | AP2, UCP, SD-JWT | Steps 6 to 9: approval, the signed purchase request, the seller’s ten checks, payment and receipts. |
| Traceability | What happened, and who is accountable? Records what happened and who is responsible in an append-only log, with a signed receipt that anyone can check offline. | SCITT | Steps 10 and 11: ledgers checkpointed in a public log; the verifier replays them. |
| Trust | How far should this agent be trusted? Turns a verified identity into an evidence-based score computed from public attestations rather than self-description. | Open Trust Index | Before approval: the approval service checks the seller’s open Trust Index score against the person’s minimum. |
The prototype
Four parties, three clouds, four domains, one chain
A flight from Madrid to Singapore, bought by agents that do not know each other in advance and share no platform. Each party verifies the others through published records and signatures. Rogue agents, a lookalike seller and forged requests among them, are stopped before any transaction takes place.
buyer.onbehalf.dev · AWS
Buyer agent
Works for the person. Finds the seller, checks it, collects signed prices, asks for the person’s approval and completes the purchase.
seller.skybound-travel.com · Cloudflare
Seller agent
Open to anyone who searches for a flight. Signs every price it quotes, and completes a checkout only under a mandate it can verify.
sealedby.dev · Google Cloud
Approval service
Where the person says yes. Shows what is being bought, applies the person’s own limits, and signs the mandate the seller checks.
provedby.dev · Google Cloud
Independent verifier
No prior relationship with any party. Repeats the others’ checks from their public records and publishes a signed verdict.
Before buying, the buyer runs fourteen checks on the seller; before charging, the seller runs ten on the buyer. See every check.
What the chain guarantees
A verifier can reach a conclusion without trusting any participant
01
Observable
Every link is published or logged where a counterparty, a regulator or an auditor can see it. Nothing rests on a private assurance between two parties.
02
Authenticated
Critical claims are cryptographically bound to their identity and authorization evidence. A claim at one layer cannot stand if the layer beneath it does not check out.
03
Tamper-evident
Every link is signed and recorded, so any later alteration can be detected. The record of what an agent did cannot be quietly rewritten.
Governance
Mapped to IMDA’s Model AI Governance Framework for Agentic AI
The framework asks that each agent’s identity be unique, accounted for, differentiated by the capacity in which it acts, and catalogued; and that its authority be scoped, time-bound, non-transferable and bounded by the person who grants it. The case study sets out the evidence for each. In summary:
| Criterion | Evidence in the prototype |
|---|---|
| Unique | Each agent has its own DNSSEC-signed domain; every host’s server key is pinned in DNS with DANE; each running instance holds its own SPIFFE identity. |
| Accounted for | Each agent is tied to the owner of its domain, and ANS records each registration in a transparency log. Each purchase is tied to the person who approved it with a passkey. |
| Differentiated by capacity | The buyer searched on its own account, and bought only on the person’s behalf under signed AP2 mandates. The ledger records both capacities. |
| Catalogued and managed | The seller is published with DNS-AID and in its zone’s ARD catalogue, and registered in ANS. The operator can withdraw an agent’s key or DNS record whenever it chooses. |
| Scoped, least privilege, non-transferable | The mandates cover one seller, one flight, one payee and one amount, for a bounded time, and work only with the buyer agent’s own key. |
| Bounded by the person’s permissions | The approval service applies the person’s own limits before signing: a per-purchase ceiling, period budgets, blocked sellers and a minimum seller trust score. |
What this does, and doesn’t, claim
- Control of a domain shows who operates an agent. It leaves open the operator’s legal identity, and domains are cheap: a buyer should weigh a domain it has never seen accordingly.
- A transparency log proves a record existed unaltered at a point in time. It does not vouch for the record’s content.
- The prototype is a simplified reference architecture, offered as a starting point. Payments in the demonstration run in Stripe test mode; in the labs they are simulated. No real money moves.
Adopt and extend it