Specoria
Menu
TR Free test

InsightsInfrastructure

When the agent checks the store: what the Chain of Trust demo means for your domain

On 14 October GoDaddy, Infoblox, Google and Cloudflare showed AI agents verifying a seller through DNS before buying. What was demonstrated, what is still a draft, and the groundwork a store can do today.

By 8 min read
A cut-paper collage of a stone arch doorway beside a paper browser frame, with a plaster hand holding a key and a thin violet ribbon linking them.
Before the agent buys, it knocks at the door and asks who really stands behind it. Illustration: Specoria · generated with AI

Most of what has been written about agent identity, including our own guide, looks at one direction: how a shopping agent proves to your store that it is a legitimate agent and not a scraper. Web Bot Auth, signed requests and the card networks' agent programs all answer that question.

On 14 October 2026, four infrastructure companies showed the other direction. At GovWare 2026 in Singapore, GoDaddy, Infoblox, Google and Cloudflare demonstrated a buyer agent that checked who the seller was before it spent a cent. The seller had to prove that it really controlled its domain, that its agent was registered, and that the price it quoted was the price it would charge. The companies call the setup a "Chain of Trust".

It is a prototype, payments ran in test mode, and several of the standards involved are still drafts. But it is the clearest public picture so far of what an agent might check about a store, and most of it starts with something every store already has: a domain name.

What was demonstrated

According to the press release and the technical case study published on openagentcommerce.org, the scenario was a flight purchase from Madrid to Singapore. Four agents took part, each run independently on a different platform:

  • A buyer agent on Amazon Web Services, acting for a person.
  • A seller agent on Cloudflare Workers, quoting prices and taking the order.
  • An approval service that recorded the person's consent and issued signed spending permissions.
  • A verifier on Google infrastructure that repeated the checks from public records and published its own signed verdict.

The person approved the purchase with a passkey. The approval service then issued signed mandates under Google's Agent Payments Protocol (AP2), limited to one seller, one flight, one payee and one amount, for a bounded time. The buyer found the seller through DNS, checked its identity against a public log, and completed the purchase over the Universal Commerce Protocol (UCP), with payment through Stripe in test mode. Every step was written to an append-only log.

The press release says the demo also included a look-alike seller and forged credentials, and that the chain stopped each one before any transaction. The case study describes the forged and tampered requests in more detail: "Every forged and tampered request was refused, and none led to a payment." It does not describe a separate look-alike seller test; it notes only that a look-alike domain inherits none of the trust attached to the real one.

The work was developed with Singapore's Infocomm Media Development Authority (IMDA) and maps to its Model AI Governance Framework for Agentic AI, version 1.5, published in May 2026.

What the agent actually checked

Paper price tags and a torn receipt lie beside a sealed envelope and a stack of parcels, with a violet wax seal as the only colored accent.
A price on a tag only holds if the final receipt says exactly the same thing. Illustration: Specoria · generated with AI

The case study is unusually specific. Before sending its first query, the buyer ran fourteen checks on the seller. Nine were about identity, five about commerce. In plain terms, the buyer wanted to know:

  • Does this domain really belong to the seller? The seller published a DNS record pointing to its agent, signed with DNSSEC, plus DANE records that tie the domain to the server's certificate.
  • Is the agent registered? The seller's agent was registered in the Agent Name Service (ANS), a registry anchored to DNS with entries in a public transparency log.
  • What does the agent offer, and is that description untampered? The seller published a signed agent card and a UCP profile listing its signing keys, its payment handler and which mandate issuers it accepts.
  • Is this quote genuine? Each price the seller quoted was signed, so the buyer could recompute it and detect changes.

The seller, in turn, ran ten checks on every checkout request before touching money. One of them matters to any merchant: the seller, currency and amount in the mandate had to match the checkout total. If the total at checkout differed from what the person approved, the mandate would not cover it, and the seller would refuse with a typed error.

What is settled and what is not

It is easy to read a demo like this as a finished standard. It is not, and the case study says so itself.

  • Several pieces are drafts. ANS and DNS-AID, the DNS-based discovery method, are IETF Internet-Drafts. ANS is an independent submission led by GoDaddy, not a working group standard. Agent Resources Discovery (ARD) is a community specification at version 0.91.
  • A record is not a guarantee. In the case study's words, "A log proves that a record existed unaltered at a point in time; it does not vouch for the record's content." A domain shows which organisation runs an agent, not whether that organisation is honest.
  • Trust scoring is a choice. The demo used an open Trust Index score, and the case study is clear that each organisation decides how much weight to give it.
  • No product, no date. The release gives no availability, pricing or rollout plan. The companies invite registrars, DNS operators, payment networks and platforms to adopt the architecture.

So nothing here requires a store to act this month. What the demo does show is where the checks are likely to land: on your domain, on the consistency of your prices, and on whether your systems can say, in a signed and machine-readable way, what they will do.

What this means for a store

Three points apply whether or not your platform ever adopts this exact architecture.

  • Your domain becomes part of your identity for machines. In this model the buyer starts from the domain alone. If the domain's DNS is unsigned, poorly managed or controlled by someone who left the company, everything built on top is weaker. Look-alike domains, which phishing already uses against people, are exactly what signed DNS and registries are designed to separate from the real store.
  • A quote is a promise. When the price an agent sees has to match the amount the person approved, any surprise at checkout breaks the purchase. A shipping fee added at the last step, a price that differs between your feed and your page, or a discount that only applies after login turns into a refused order, not a mildly annoyed shopper. We wrote about why your feed, page and structured data should agree on price; signed quotes make that agreement enforceable.
  • Most of the work will sit with your platform. Publishing signed agent cards, UCP profiles and ANS registrations is the kind of thing a commerce platform does for thousands of stores at once, the way it already handles TLS certificates. Independent stores on hosted platforms will mostly depend on what their provider supports.

What to do now

None of these steps depends on the drafts becoming standards, and each one helps with people as well as agents.

  1. Know who controls your domain. Check which registrar account holds it, who has access, whether two-factor login is on, and whether renewal is automatic. A lapsed or hijacked domain is the one failure no protocol can repair.
  2. Ask about DNSSEC. Many DNS providers offer it as a setting. Ask yours whether it is available for your domain and what turning it on involves; a misconfigured DNSSEC change can take a site offline, so do it with whoever manages your DNS.
  3. Use one canonical domain everywhere. Product links in your feed, the URLs in your structured data and the address your checkout runs on should point to the same domain, or to subdomains you clearly own. Mixed domains are harder for any verifier to tie together.
  4. Watch for look-alikes. Search for close misspellings of your domain and brand now and then. If someone is impersonating your store, a dispute process such as ICANN's UDRP exists for exactly this, and the case study names it.
  5. Remove surprises between product page and checkout. Show shipping costs and the final price as early as you can, and keep your feed, page and structured data in sync. This is the step most likely to matter first, with or without signed quotes.
  6. Ask your platform about UCP and agent identity. If you are on Shopify, WooCommerce, ikas, Ticimax, IdeaSoft or T-Soft, ask whether UCP profiles, signed agent cards or registries like ANS are on the roadmap, and what you would need to configure.

The bottom line

The Chain of Trust demo is a prototype built on draft standards, with no product or date attached. What makes it worth reading is the direction it confirms: agents will not only identify themselves to stores, they will also check stores before they buy, starting from the domain and ending at the checkout total. A store with a well-managed domain, one canonical address and prices that do not change between the product page and the final step is already doing the groundwork that this model rewards.

Specoria checks the parts of that groundwork a store controls today: whether your feed, page and structured data agree, what your checkout reveals at each step, and where a real browser agent stops on the way to the basket. Start with a free readiness test.

Sources