GoDaddy, Infoblox, Google and Cloudflare are demonstrating Chain of Trust with Singapore’s Infocomm Media Development Authority (IMDA) at GovWare 2026, which runs October 13–15. The test follows a simulated flight purchase from Madrid to Singapore across independently operated agents. It uses Stripe test mode, so no real funds move. The project’s event page gives the event dates, and its technical case study details the transaction flow.
Chain of Trust is an early-stage reference architecture for checking an agent’s identity and authority separately. Its test brings together four agents across three cloud providers and four domains, without a shared platform or prior arrangement between buyer and seller.
The four agents and what each one does
The buyer agent finds a seller, checks its records, gathers signed quotes and submits the purchase request. The seller agent publishes its commerce profile and quotes, then checks for valid authorization before proceeding. A separate approval service issues the signed mandates that constrain the purchase; an independent verifier replays checks against published records and the mandate chain.
The test places the buyer on AWS, the seller on Cloudflare, and the approval service and verifier on Google Cloud. A person’s own AI assistant connects to the buyer agent through MCP. The roles remain distinct: the buyer makes the request, while the person approves it and another service issues the agent’s authority. The case study describes the four-agent setup and its connections.
From seller discovery to independent verification
The flow starts with a person signing in with a passkey and asking the buyer agent to make the purchase. DNS-based discovery helps the buyer find the seller; the buyer then runs 14 checks on the seller before collecting signed price quotes. The person approves the proposed purchase with a passkey, after which the approval service issues two signed AP2 mandates.
The buyer sends a signed checkout-completion request. Before handling payment, the seller runs 10 checks, including whether the mandate is valid. Stripe then processes the simulated payment in test mode, and the participants create signed receipts and ledger checkpoints. An independent verifier checks the records and mandate chain. The project’s technical account lays out these checks and stages.
The protocol names reflect different jobs rather than one all-purpose mechanism: DNS supports discovery, MCP connects the person’s assistant to the buyer, A2A supports agent communication, and UCP carries commerce and checkout requests. The case study identifies DNS-AID and ANS as IETF Internet-Drafts and ARD as a community specification, so the demonstrated stack includes proposals and community specifications alongside established protocols.
How human approval limits the agent’s authority
The person’s approval does not give the buyer agent unrestricted power to spend. In the test, one AP2 mandate is limited to a specific seller and checkout; the payment mandate specifies one payee and an amount. Both are time-limited and bound to the buyer agent’s key, and the buyer agent cannot issue mandates itself.
The person can stop the agent or cancel an approval. The seller checks the approval service’s current mandate status, while an operator can withdraw an agent key or remove its DNS record. Those controls make authorization a separate step from identifying which agent sent a request. The case study details the mandate limits and revocation controls.
What the test records can—and cannot—show
The project reports that the seller rejected the forged and tampered requests tested, and none resulted in payment. Each participant also kept a hash-chained ledger, with signed checkpoints registered with a verifier and a public SCITT transparency log. A transparency log can show that a record existed unaltered at a particular point in time; it does not establish that the record’s contents are true.
The public ledgers served as an illustration in this test. The project’s case study says commercial participants are expected to keep ledgers private and give selected verifiers access. With Stripe in test mode and no real funds moved, Chain of Trust remains a reference architecture for further testing—not a broadly deployed payment service.
