Open Agent Commerce

How it works

Eleven steps, five questions

Every purchase between agents that have never met answers the same five questions, in the same order. Here is what happens underneath each one.

Where is it?

Step 1

Request

A person asks an AI app to do something, such as book a flight. The app hands the request to a buyer agent, typically over the Model Context Protocol (MCP).

Step 2

Discovery

The buyer agent knows only the seller's domain, not whether it runs an agent at all. It asks DNS. A DNS-AID record under that domain says an agent exists, where it lives, which protocol it speaks, and where to find its metadata. Where a domain runs several agents, a catalogue lists them all from one query.

Is it really them?

Step 3

Identity

The buyer follows a chain: signed DNS records (DNSSEC), to the agent's HTTPS endpoint, optionally checked against a signed TLSA record (DANE), to the agent's own Agent Card, to an ANS registration confirming the operator controls the domain and logging that registration in a public log. This is domain-validated: it shows the domain vouches for the agent, not which company sits behind the domain.

Step 4

Capabilities

The seller publishes what it can do and how to use it: an A2A agent card, an MCP tool list, and a UCP profile that states what checkout it accepts, which approval services it trusts, and its spending ceiling for a buyer it has never met.

Did a human say yes?

Step 5

Signed, time-limited quote

The buyer searches, which needs nobody's permission since looking changes nothing, and the seller returns a quote: priced, signed, and valid for a short window only.

Step 6

Approval and mandate

The quote goes to a separate approval authority, on its own page, deliberately outside any agent. The person approves with a passkey. The authority checks the purchase against the person's own limits, then issues a mandate: signed, naming this seller and this quote, locked to the buyer agent's key, and valid for a few minutes. In the demonstration this authority is run by the demo team, and we say so; it is shaped so a bank or another regulated party could run it instead.

Does the seller enforce it?

Step 7

Signed purchase request

The buyer goes back to the seller with the mandate attached, plus a short statement of its own, signed with its key and tied to this specific checkout. That signature is what makes a copied mandate worthless without also holding the key it is locked to.

Step 8

Seller enforcement

Before charging anything, the seller runs a fixed sequence of checks in code, in order: the request is signed by a key the buyer has published; the mandate is signed by an approval authority the seller accepts; the mandate is locked to that same key; the mandate matches the checkout unchanged; and the mandate has not expired, been used before, or been revoked. None of this relies on politely asking an AI model to behave.

Can anyone check it later?

Step 9

Payment and receipts

Payment runs as a test-mode payment intent in a payment processor's test environment, never a real charge. The seller returns two signed receipts, one for the checkout and one for the payment, each of which anyone can later match against the payment processor's own record.

Step 10

Sealed ledgers

Both agents seal their side of the exchange into their own signed ledgers, then commit a fingerprint of that ledger to public transparency logs (SCITT). From that moment, nobody, the agents included, can rewrite the history without the change showing.

Step 11

Independent verification

A verifier, run separately from the buyer and seller, replays the evidence from every side and publishes a scorecard across nine dimensions. Nobody in the demonstration grades their own work.

Architecture

Four agents, three clouds, four domains, and a band of public infrastructure that none of them owns.

Open Agent Commerce reference architectureA person instructs a buyer agent at buyer.onbehalf.dev. The buyer agent discovers and verifies a seller agent at travel.agenthaven.dev, and requests approval from an approval authority at sealedby.dev. An independent verifier at provedby.dev reads public evidence from all three, without taking part in the transaction. A rogue agent, shown in red, is refused by the seller. All four rely on shared public infrastructure: DNS and DNSSEC, the ANS registry and its transparency log, a SCITT witness, and test-mode payments. Solid green lines are signed messages between parties. Dotted blue lines are the verifier reading public evidence only.PersonpasskeyBuyer agentbuyer.onbehalf.devSeller agenttravel.agenthaven.devRogue agentlookalike / forgedApproval authoritysealedby.devIndependent verifierprovedby.devrequestquote / purchasemandaterefusedreads ledgerreads ledgerreads recordsPUBLIC INFRASTRUCTURE, SHARED BY ALL PARTIESDNS + DNSSECANS registry + transparency logSCITT witnessTest-mode payments
solid = signed dotted = read-only red = rogue agent, refused

Standards glossary

Nothing here was invented for this demonstration. Where a link is missing, it is because we are not confident enough in a stable URL to publish one.

DNS-AID
A proposed internet standard for publishing an AI agent's location and capabilities in the DNS records of the domain that runs it, the way SVCB records already publish a service's connection details.
ANS
The Agent Name Service. An ANS record confirms the operator controls the domain, issues the agent's identity certificates, and records the registration in a public log.
DNSSEC
Domain Name System Security Extensions: lets the owner of a DNS zone cryptographically sign its records, so a resolver can tell the answer came from that zone's owner and wasn't altered in transit.
DANE / TLSA
DANE lets a domain owner publish, in a signed TLSA record, exactly which certificate or key its server should present, so an impostor at the same address cannot pass the check.
A2A
Agent2Agent: an open protocol, now under the Linux Foundation, that lets agents talk to one another directly. Each agent publishes an agent card describing who runs it, where to reach it, and what it can do.
MCP
The Model Context Protocol: an open protocol that lets AI applications call tools and agents. In this flow, it is the doorway a person's AI app uses to hand a request to a buyer agent.
UCP
The Universal Commerce Protocol: an open standard for shopping between agents and businesses. A seller publishes a profile of what it supports, including checkout, payment methods and accepted approval services.
AP2
The Agent Payments Protocol, maintained by the FIDO Alliance. It defines a mandate, a signed statement that a person has allowed an agent to buy something, within limits, until a set time, checked outside the agent itself.
SPIFFE / SPIRE
SPIFFE gives each running copy of an agent its own workload identity, written like a URI beginning spiffe://. SPIRE is the software that issues and rotates those identities.
SCITT
An architecture for transparency logs: public, append-only records. Each entry gets a receipt that anyone can check later, and nothing already logged can be changed or removed without it showing.
Passkeys
The fingerprint, face or device-PIN check already used to unlock a phone or sign into many websites, used here to show that the person holding the device approved a specific purchase.

What we don’t claim

  • We don’t say “identity verified.” We say the domain vouches for the agent. An ANS registration is domain-validated; it doesn’t prove which company is behind the domain.
  • We don’t say “payment completed.” Payments run in a payment processor’s test mode. We say “test-mode payment intent.” No real money moves.
  • The approval authority in the demonstration is run by the demo team, and we say so plainly. It is built so a bank, or another regulated party, could run it instead.
  • This site does not claim government endorsement or certification of any kind.