14 October 2026 GoDaddy, Infoblox, Google and Cloudflare Demonstrate Secure AI Agent Transactions Across Platforms. Read the press release →
Open Agent Commerce

Engage with us

An open project. Two ways in.

Open Agent Commerce is a reference architecture built on open standards anyone can implement. It shows how AI agents from different companies can find each other, prove who they are, get a person’s approval and transact, while rogue agents are refused and the refusal can be proved afterwards.

You can take the standards and build on them yourself, or work with us directly. Either way, the conversation happens in the open.

  • Agent builders
  • Sellers and merchants
  • AI platforms
  • DNS operators and registrars
  • Identity providers
  • Payment networks
  • Security teams

Join the conversation

The team is on Discord, and the channel is public.

Discord

Talk to the team

Ask questions, compare notes with other implementers, and tell us what you are building. The people who built the demonstration read the channel.

The on-ramp

Pick your path

If you want to implement this yourself, the basic information is here. If you need a more guided approach, contact us and we can work with you.

Path A

Implement it yourself

For teams with engineers and a domain of their own. Nothing here was invented for the demonstration, so you can build with the tools you already have and ask us when you get stuck.

  • Understand the flow and the four ideas behind it.
  • Try it hands-on in a sandboxed lab, no install.
  • Build against the seller and buyer checklists.
  • Share what you built and get it checked.

Path B

Work with us

For organisations that want a guided approach: a conversation first, then a scoped piece of work with the team that built the demonstration.

  • Scope what agent commerce means for your business.
  • Run a pilot in a sandbox before anything touches production.
  • Bring your own domain, agent, registry or payment rail into the flow.
  • Review what you have already built against the architecture.

Path A

Implement it yourself

Four stages, in order. Each one is useful on its own, and you can stop at any of them and still have learned something you can use.

  1. Understand it

    One purchase between two agents that have never met, in eleven steps, under five questions: where is it, is it really them, did a human say yes, does the seller enforce it, can anyone check it later.

    Read how it works, including the architecture and a glossary of every standard involved.

  2. Try it hands-on

    Two self-paced labs, each a sealed sandbox with its own signed DNS, seller, buyer, approval authority, registry and verifier. The Guided Tour takes about fifteen minutes and needs nothing installed. The Builder track takes about an hour: sign your own zone, publish your agent, approve a purchase, then attack your own seller and read the verifier’s scorecard.

    Open the labs. Nothing in a lab touches a public system, and payments are simulated.

  3. Build

    Work through the checklist for your side of the transaction, below. Each step says what it achieves first and names the standard that carries it second, so you can brief the people who own the domain, the agent, the approvals and the audit trail separately.

    Go to the checklists.

  4. Share and verify

    Post what you built in the Discord channel and we will help you check it against the architecture. Found a gap, or built something others could use? Tell us there too.

What you are implementing

Every item on the checklists serves one of four ideas. Rogue agents fail at least one of them: a lookalike seller, an agent spending without approval or beyond its limits, a replayed or tampered request, a transaction with no audit trail.

  • The domain vouchesAn agent's identity is anchored in the domain of the organisation that runs it, so a lookalike seller cannot pass as the real one.
  • A person says yes, within limitsApproval is signed by a separate authority, outside any agent, and names this seller, this quote, this agent, for a few minutes only.
  • Sellers enforce in codeBefore any charge, the seller checks the signatures, the limits and the freshness of the approval. A copied or expired approval is refused.
  • Signed records anyone can verifyBoth sides keep tamper-evident ledgers and commit fingerprints to public logs, so what happened can be proved afterwards by someone who was not there.

The checklists

Deliberately conceptual. The standards move and the exact steps for your stack will differ; treat these as the questions your implementation has to answer. The standards glossary on the how it works page has the references.

Seller

If you sell through an agent

  1. Run your agent under a domain your organisation controls, and sign that domain so nobody can forge answers about it.

    DNSSEC

  2. Announce the agent in your domain, so a buyer who knows only your name can find it, and find the right one if you run several.

    DNS-AID · catalogue at /.well-known/ard.json

  3. Pin your agent's HTTPS certificate in your domain, so a lookalike at the same address fails the check.

    DANE / TLSA

  4. Register the agent, so its registration is on a public record and anyone can confirm the domain vouches for it.

    ANS

  5. Publish what the agent is and what it accepts: how to reach it, what it can do, which approval authorities you trust, and the most a stranger may spend.

    A2A agent card · MCP tool list · UCP profile with the AP2 mandate extension

  6. Sign every quote and give it a short life. Never complete a purchase without a valid approval that matches this quote.

    Signed quotes · AP2 mandates

  7. Enforce in code, in a fixed order, before charging: the request is signed by a key the buyer has published; the approval comes from an authority you accept; it is locked to that same key; it matches the checkout unchanged; and it has not expired, been used before or been revoked.

    AP2 mandate verification · replay and revocation checks

  8. Keep a signed, hash-chained record of what your agent did, and periodically commit its fingerprint to a public transparency log.

    Signed ledger · SCITT

Buyer

If you buy through an agent

  1. Give your agent an identity your organisation stands behind: a domain of its own, or a workload identity tied to where it runs.

    DNSSEC-signed domain · SPIFFE / SPIRE

  2. Check a seller before you transact: the signed answers from its domain, the pinned certificate, the public registration. Treat any failure as a refusal, and consider a trust-scoring service on top.

    DNSSEC · DANE / TLSA · ANS

  3. Keep human approval outside the agent. A separate authority lets the person approve a specific quote, checks it against their own limits, and issues a short-lived approval locked to your agent's key.

    AP2 mandates · passkeys

  4. Sign each purchase request with your agent's key and tie it to that specific checkout, so a copied approval is worthless without the key.

    Signed requests · AP2

  5. Keep your own signed record of what the agent did and commit fingerprints to a public log, so a dispute can be settled from evidence rather than recollection.

    Signed ledger · SCITT

Path B

Work with us

If you would rather not start from a checklist, tell us where you are and we will work out the next step together.

What that usually looks like:

  • Scoping. A working session on what agent commerce means for your organisation, which side of the transaction you are on, and what you already have in place.
  • A pilot. Your agent, or your domain, inside a sandbox like the one behind the labs, with the attacks run against it and the verifier’s scorecard to show for it.
  • Integration. Bringing a domain, an agent, a registry, an identity service or a payment rail into the flow, and working out what the standards still leave open.

Open Agent Commerce is built by Infoblox and GoDaddy and is demonstrated at GovWare 2026. We read every message and will follow up.