On 14 October, GoDaddy, Infoblox, Google Cloud and Cloudflare showed four AI agents from different organisations completing a flight purchase with no shared platform between them. The demo ran at GovWare 2026 in Singapore, and a technical case study followed on 15 October. Each agent found and checked the others using public records: signed DNS, a public agent registry, published agent cards and transparency logs.

The commerce step ran on the Universal Commerce Protocol. The seller published a UCP profile, the buyer checked it before sending anything, and the purchase completed over UCP's REST binding with an AP2 mandate. Every record in the demo is public, so we checked them with our own tools. Almost everything holds up, and UCP's role turns out to be bigger than "the checkout step".

#What is the Open Agent Commerce chain of trust?

The chain of trust is a reference architecture for letting AI agents that have never met verify each other's identity and authority before they transact. It was published as Open Agent Commerce with a technical case study written by engineers at Infoblox and GoDaddy. The case study maps the result to Singapore IMDA's Model AI Governance Framework for Agentic AI.

The demo has four agents, each on its own domain:

The person's request came in through Claude Code, which called the buyer agent over MCP. Skybound Travel is a seller built for the experiment, and payment ran in Stripe's test mode, so no real money moved.

#Seven layers, and where UCP sits

The press release groups the standards into seven layers:

1. Discovery: DNS-AID records and an ARD catalogue say which agents a domain runs and where.
2. Identity: the Agent Name Service (ANS) registers agents, and SPIFFE names each running copy.
3. Authorisation: OAuth.
4. Communication: A2A agent cards and MCP.
5. Payment: AP2 and UCP.
6. Traceability: SCITT logs with signed receipts.
7. Trust: an open Trust Index score built from public signals.

Underneath all of it sit DNSSEC, which signs DNS answers, and DANE, which publishes in DNS the key a server must present.

#What UCP does in the demo

The case study puts it plainly: UCP is where the buyer learns "which key signs everything the seller sends". The seller's profile at /.well-known/ucp declares:

"dev.ucp.common.payment.ap2_mandate": [{
  "version": "2026-08-25",
  "extends": "dev.ucp.shopping.checkout",
  "config": {
    "dev.agenthaven.mandate_forms": ["ap2-v0.2-delegate-chain"],
    "dev.agenthaven.mandate_issuers": [
      "https://authority.skybound-travel.com",
      "https://authority.webmesh.ai",
      "https://sealedby.dev"
    ]
  }
}]

That is the AP2 mandate extension from UCP v2026-08-25, on top of checkout and catalog search, with a P-256 signing key in the profile's keys[]. The dev.agenthaven.* fields are the operator's own namespaced settings, which list the approval services the seller accepts mandates from.

Before sending a query, the buyer ran fourteen checks on the seller. Nine concern identity: DNS signatures, DANE, the card's fingerprint and the ANS registration. Five are UCP checks:

• ucp_profile: the profile is well formed.
• ucp_negotiation: buyer and seller share capabilities.
• ucp_key: the profile carries the same key the running seller uses.
• ucp_handler: there is a payment handler the buyer can use.
• ucp_issuers: the seller accepts the approval service the person uses.

Then the purchase itself:

1. The seller returned two signed quotes.
2. The person approved with a passkey, and the approval service signed two AP2 mandates.
3. The buyer bound both mandates to its own key and to one checkout session, and sent a signed completion request over UCP REST.
4. The seller ran ten checks before touching money: the signed request, the buyer's identity, the issuer allow-list, amount equals checkout total, the quote unexpired, single use and not revoked.

On stage, rogue agents tried six ways to cheat: a lookalike seller, a buyer over its ceiling, a replayed order, a tampered order, a cancelled approval and a withdrawn identity. Each was refused in code by the party it targeted, with a reason code written to the record. The demo also ran the purchase between two teams' agents built with no shared code, meeting only at the open standards.

#What we verified

We ran the public parts of the demo through our tools on 15 October:

The second row is the one we'd underline. UCP lets a business authenticate a buying platform it has never met by fetching the profile the platform names on each request and checking the request signature against that profile's keys. The spec describes this. Here, a live seller enforces it on its UCP REST endpoint: no fetchable platform profile with a signing key, no catalogue search.

The other thing the records show is that the profile is doing identity work. Under the AP2 extension, the business signs every checkout response with a key from its profile's keys[], and the buyer checked that this is the same key the running seller uses. The profile is the published record a buyer checks the seller against.

#What it shows, and what it doesn't

It shows that the parts of UCP built for this already work across organisations:

• profiles as a source of keys
• platform authentication by profile
• the AP2 mandate extension negotiated on checkout

The demo never needed a shared directory or shared code. Every check can be repeated from a domain name, which is the case study's main argument.

It doesn't show a product or a market:

• It's a prototype, run with a demo seller and test payments.
• Several layers are still drafts, and some are the authors' own. DNS-AID is an IETF Internet-Draft with Infoblox authors, and ANS is one with a GoDaddy author; ARD is a v0.91 community spec. The demo is also the front door to the project's labs and its sign-up for organisations that publish agents. UCP, AP2, A2A and MCP come from other groups.
• The deployment runs older versions of A2A and MCP than the ones its annex cites.
• It's a heavy stack. One purchase touched about sixteen standards.
• Adoption is early. On our capabilities page, the AP2 mandate extension is declared by 7 stores as of 15 October.

For travel specifically, the hardest part UCP hasn't specified is an offer that expires and has to be held through to booking. The demo handled it with its own signed quote format: each fare quote is signed by the seller, carries an expiry, and the seller re-checks it before completing. That is the same gap our expiring travel inventory study found agents falling into. It's also close to what Google's quote extension proposal describes for B2B: a business-issued quote with its own id and expiry. Travel has no UCP charter or namespace yet; see UCP for Travel.

#What it means for stores and agent builders

For stores, nothing changes today. But the demo is a clear picture of what a careful buyer agent reads first, before any product data:

• the signing keys in your profile's keys[]
• your payment handlers
• for AP2, which approval services you accept

If those fields are missing or wrong, a verifying agent stops at check one.

For agent builders, publish a platform profile with your signing key and sign your requests. Sellers that enforce platform authentication, as this one does, will refuse anything else.

#What we'll watch

• Whether the AP2 mandate extension appears on more live stores, and with which approval services.
• Whether a travel charter or namespace is filed, and whether it adopts a quote or offer object with an expiry.
• How the UCP Payments council's roadmap treats mandates and approval services.
• Whether DNS-AID and ANS move forward at the IETF.

#FAQ

What is the Open Agent Commerce chain of trust? It's a reference architecture from GoDaddy, Infoblox, Google Cloud and Cloudflare for letting AI agents from different organisations verify each other before they transact. It uses signed DNS, an agent registry, agent cards, AP2 mandates and transparency logs. It was demonstrated on 14 October 2026 with a simulated flight purchase.

Does the demo use UCP? Yes. The seller publishes a UCP v2026-08-25 profile with checkout, catalog search and the AP2 mandate extension. The buyer runs five UCP checks before buying, and the purchase completes over UCP's REST binding.

Is this a product I can use? No. It's a prototype with a demo seller and test-mode payments. The case study and hands-on labs are public, and organisations can register interest on the Engage page.

What is an AP2 mandate in UCP? It's a signed statement that a person approved an agent to buy something, within limits and for a set time. UCP's AP2 mandate extension lets a business require one on checkout, and requires the business to sign its checkout responses.

How does a UCP seller know which buyer agent is calling? The buyer names its UCP profile on each request and signs the request with a key published in that profile. The seller fetches the profile and checks the signature. In this demo, the seller refused our unsigned request because there was no profile with a key to check.

Does UCP support flights? Not yet. UCP has no travel namespace or charter. The demo used UCP's general checkout and catalog search, plus its own signed quote format for fares.

Can I check a seller's UCP profile myself? Yes. Run the domain through UCP Checker or the UCP Validator to see its version, capabilities, payment handlers and signing keys.

#About UCP Checker

UCP Checker is the independent validation and observability layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score, live adoption stats, the vertical guides and the authority-bound vendor map, and track the spec as it evolves so you don't have to — measured from two vantages (what a business declares, and what actually happens when an agent transacts), the same way for everyone, without picking winners.

#Sources

• GoDaddy, Infoblox, Google and Cloudflare Demonstrate Secure AI Agent Transactions Across Platforms, PR Newswire, 14 October 2026
• Implementing the Chain of Trust for an Agentic Transaction, technical case study, Open Agent Commerce, 15 October 2026
• The demonstration (video, 9 min 29 s), labs and live flow monitor, Open Agent Commerce
• AP2 mandates extension, UCP specification v2026-08-25
• UCP release v2026-08-25, UCP GitHub
• DNS-AID and ANS, IETF Internet-Drafts
• AP2 releases, GitHub
• Issue #929: Quote extension proposal, UCP GitHub, open

Related coverage: UCP for Travel · We tested 5 AI models on expiring travel inventory · Amazon's business directory and identity RFCs · The UCP Payments council