Written by Jeremy Souffir Founder, JTS Tech Services
The short version, and the direct answer if you read nothing else. On 14 October, at a cybersecurity conference in Singapore, GoDaddy, Infoblox, Google and Cloudflare demonstrated AI agents from different companies completing a purchase in which the buying agent verified the seller before it paid. It looked the seller up in DNS, checked that the records were cryptographically signed, matched the site's certificate against a key published in those records, confirmed a public registry entry, and read the seller's own commerce profile. The organisers say a look-alike seller and forged credentials were stopped before any transaction. Nothing here is a product you can switch on, and payments ran in test mode. But the direction is clear: when an agent shops for your customer, the thing standing between your store and a convincing copy of it will be your domain and your DNS, not your logo, your reviews or your theme.
What was actually shown?
The scenario was a simulated flight purchase, built as an open reference architecture with Singapore's Infocomm Media Development Authority and unveiled at GovWare 2026. A person approved the purchase with a passkey. A separate approval service turned that approval into a signed instruction limiting what the buyer's agent could buy, from whom, and up to what amount. The buyer's agent ran on AWS, the seller's agent on Cloudflare, and the approval and verification services on Google. None of them had dealt with each other before.
The interesting part is the order of operations. Before it spent anything, the buyer's agent ran the checks a careful human buyer would like to run on an unfamiliar shop and never can:
- Is this the real domain? It found the seller through DNS records that were signed with DNSSEC, the long-standing standard that lets anyone check a DNS answer was not forged in transit.
- Is this the real server? It compared the certificate the site presented with a fingerprint published in those signed records, a standard called DANE. A copy of the site on another server would not match.
- Is this a registered seller? It checked an entry in a public agent registry and an append-only log, so a seller cannot quietly change its identity after the fact.
- What does this seller accept? It read the seller's commerce profile, published at a fixed address on its own domain under the Universal Commerce Protocol, which lists its signing keys, payment methods and the approval services it trusts.
- Does it meet the buyer's bar? It compared the seller's public trust score against a minimum set in the buyer's own limits.
Only then did the payment go through, over UCP with Stripe. Each refusal along the way was written to a public log.
Whose claims these are, and where they stop
What is confirmed and what isn't
Confirmed: the demonstration took place on 14 October, the architecture and a technical case study are published, and an independent check by UCP Checker the next day found the seller's signed DNS, certificate match, registry entry and commerce profile all live and valid. Claimed by the organisers but not shown in detail: that a look-alike seller was stopped. The technical paper describes forged and tampered requests being refused, but does not describe the look-alike test itself. Early by any measure: several layers are still IETF drafts, some written by the demo's own authors, the trust score has no published formula, and UCP Checker counted 7 stores declaring the payment-approval extension the demo relied on.
So read this as a working sketch from four companies with a commercial interest in the outcome (GoDaddy sells domains, Infoblox sells DNS), not as a standard that has arrived. It is still worth your attention for one reason: it is the first serious public answer to a question every merchant should be asking now that agents are starting to buy.
Why should a store owner care about a flight demo?
Because the problem it solves is already yours. Look-alike stores are an old fraud: a near-identical domain, a scraped catalog, prices slightly too good. Humans fall for them because they judge a shop by how it looks. An agent shopping for your customer judges it by what it can read, and a scraped copy of your product pages reads exactly like you. Until now nothing in the agent buying flow had a reliable way to tell the two apart.
We have written about the agent's side of identity: in August, when agents started getting verifiable IDs and capped wallets, and last week, when Meta and Sierra proposed that shopping agents get their own sign-in at your store instead of borrowing your customer's password. This is the mirror image. The agent proves who it is to you; now you prove who you are to the agent. And the evidence it reaches for is the plumbing under your website: who controls your domain, whether your DNS is signed, and what your domain publishes about you.
The two conclusions that both get this wrong
It's a demo about flights, so it's someone else's news
The flight was a stand-in. The checks are generic, and the commerce profile they read is the same Universal Commerce Protocol that TikTok's Buy Direct and Google's Merchant Center hub now require. More to the point, the one thing every layer depends on, control of your domain, is something you can lose today, demo or no demo. A hijacked registrar account already means a hijacked store; in an agent-verified world it would also mean a hijacked identity that checks out as genuine.
Register everywhere now so we are first in line
There is no merchant switch to flip and no programme to join that a shopping agent is using in production. The registry, discovery records and trust scoring are drafts that may change or be replaced. Paying anyone to put you in a registry, or to raise a trust score with no published formula, buys nothing yet. The useful work this month is the boring groundwork that every version of this will rely on.
What should you check this month?
- Find out who controls your domain. Which registrar, under whose login, with which email address, and whether that person still works for you. This is the single most common gap we see, and it is the root of everything else.
- Lock the registrar account down. Multi-factor sign-in on the account, registrar lock (sometimes called transfer lock) switched on, and auto-renew set with a payment method that will not expire quietly.
- Ask whether your DNS is signed. Most registrars and DNS hosts offer DNSSEC, often as a single setting, and some leave it off by default. Ask your DNS host before switching it on yourself, because a misconfigured change can take a site offline. If your domain is connected to a hosted platform, check what that platform supports first.
- List the look-alikes. Search for your brand name on other endings and with common misspellings. Register the few that matter, and know that disputes over abusive look-alike domains go through a formal process (UDRP) that is far easier with your trademark and records in order.
- Keep your identity consistent. The same legal business name, domain and contact details across your store, Merchant Center, your business listings and your payment provider. Every one of the proposed trust signals is built from public records agreeing with each other.
The genuinely encouraging part
Nothing on that checklist is new technology. DNSSEC and DANE are published internet standards, the commerce profile is a file your platform is already moving toward publishing, and registrar security is a twenty-minute job. As GoDaddy put it in the announcement, "We don't need to rebuild the internet for AI agents." That is good news for small stores in particular: the proof an agent is likely to ask for is the same whether you sell ten products or ten thousand, and it rewards the merchant who controls their own basics, not the one with the biggest budget.
Where we fit
This is the kind of work that falls between chairs. Your developer looks after the theme, your marketing team looks after the brand, and the domain sits under a login someone set up in 2019. We look at the whole chain in one pass: who controls your domain and registrar, whether your DNS and certificates are set up the way a verifying agent would expect, what your store already publishes to agents through your platform, and which look-alike domains are worth owning. Then we fix what is safe to fix and hand you a short, plain list of the rest. Retaining us means that when agent verification moves from demo to default, and the first assistants start refusing to pay sellers they cannot verify, your store is already the one that checks out, rather than the one your customer's agent quietly skips. If you would like a second pair of eyes on it, talk to us.
Sources
- PR Newswire: GoDaddy, Infoblox, Google and Cloudflare Demonstrate Secure AI Agent Transactions Across Platforms (14 October 2026; the seven layers, the demo and the rogue scenarios)
- Open Agent Commerce: Implementing the Chain of Trust for an Agentic Transaction (technical case study; what the seller published and the status of each standard)
- UCP Checker: UCP in the Agent Chain of Trust Demo, Verified (15 October 2026; independent verification and the adoption count)
- RFC Editor: RFC 4033, DNS Security Introduction and Requirements and RFC 6698, DANE (the published standards behind signed DNS and certificate matching)
- ICANN: Uniform Domain-Name Dispute-Resolution Policy (how abusive look-alike domains are disputed)
- JTS Tech: Agents are getting verified IDs and funded wallets, the agent gets its own sign-in and the checkout moved into the video (earlier context)
