In brief
- 01Web Bot Auth lets an automated client prove who it is by signing each HTTP request with a private key whose public half it publishes. It is a profile of HTTP Message Signatures (RFC 9421), adopted as an IETF working group draft on 1 September 2026.
- 02Visa’s Trusted Agent Protocol builds on it for commerce, with separate signatures for browsing and checkout, a short validity window, a nonce against replay, and signed objects carrying consumer recognition and payment data.
- 03Verification answers “who”, not “should I”. A valid signature proves which operator sent the request. Whether to serve it, and with what limits, is still your policy.
- 04Most retailers will verify at their CDN or bot management layer, then pass a verified agent identity to their own services. The policy and logging are where the work is.
This is a deep dive from my agentic commerce architecture blueprint, where agent identity is the foundation everything else sits on.
Why user agents and IP lists are no longer enough
For years, sites identified good bots in two ways: a declared user-agent string, and a published list of IP addresses or reverse DNS records. Both work tolerably for a few large search crawlers. Neither works for agentic commerce.
- 01User-agent strings are trivial to fake. Anyone can claim to be a well-known assistant.
- 02Agents run on shared infrastructure. Browser-based agents and agent platforms share cloud IP ranges with everyone else, so an IP list says little about who is acting.
- 03One platform, many users. An assistant used by millions sends traffic on behalf of each of them. Cloudflare now distinguishes “direct” operators from “intermediary” agentic services where the operator and the end user are different parties.
The result is that most retailers either block agents along with scrapers, and disappear from AI shopping, or allow automated traffic broadly, and invite price harvesting and fraud. Cryptographic identity on each request is the way out of that trade-off.
How Web Bot Auth works
Web Bot Auth is deliberately thin. It reuses HTTP Message Signatures (RFC 9421, published February 2024) and fixes a few parameters. Each request carries three headers:
- 01Signature-Agent: where to find the agent’s public keys.
- 02Signature-Input: which parts of the request are signed, plus parameters: a keyid derived from the key (a JWK SHA-256 thumbprint), created and expires timestamps, and the tag web-bot-auth.
- 03Signature: the signature itself, commonly Ed25519.
The verifier fetches the agent’s key set (a JSON Web Key Set) from /.well-known/http-message-signatures-directory on the origin named in Signature-Agent, rebuilds the exact string that was signed, and checks it. At minimum the target domain must be covered, so a signature captured for one site cannot be replayed against another.
Exhibit 1
Anatomy of a signed agent request and the string the verifier rebuilds
Where the standard is today
The IETF chartered a working group in October 2025. The draft moved to the Standards Track in August 2026 and was adopted as a working group document on 1 September 2026; no publication date is set. Two practical points follow from its draft status:
- 01Interoperability is still settling. Implementations have differed on the format of the Signature-Agent header, for instance. Test against the agents you care about rather than the specification alone.
- 02There is no revocation mechanism. If an agent’s key is compromised, the only remedy is removing it from the agent’s key directory, which takes effect when verifiers refresh their caches. Keep key cache lifetimes short.
What the Trusted Agent Protocol adds for commerce
Visa introduced the Trusted Agent Protocol in October 2025, built on the same signed-request foundation and developed with Cloudflare. Mastercard’s Agent Pay uses the same approach for agent recognition. Web Bot Auth tells you which operator is calling; the Trusted Agent Protocol adds what a merchant needs to transact with it.
According to Visa’s merchant specification, the agent’s signature must include @authority and @path plus created, expires, keyid, alg, nonce and a tag, and a request missing any of them should be blocked. Two details are especially useful:
- 01Separate intent tags. agent-browser-auth for browsing and agent-payer-auth for checkout, so a merchant can apply different rules to looking and buying.
- 02Tight replay protection. created and expires must be no more than eight minutes apart, and merchants should reject a nonce already seen within that window.
Beyond the request signature, the protocol defines two signed objects that travel with the request, both tied to the same nonce:
Exhibit 2
The three signed layers in a Trusted Agent Protocol checkout
Implementing verification: build, buy or both
Most retailers should not write signature verification into their application servers. The right place is the edge, where traffic first arrives, so unverified automation never reaches expensive services. In practice there are three routes:
| Route | What it involves | Best for |
|---|---|---|
| Use your CDN or bot management provider | Turn on signed-agent recognition and set policies per agent or category. Cloudflare now treats signed agents as verified bots and offers search, agent and training presets; Visa names Cloudflare and Akamai as implementation partners | Most retailers |
| Verify in your own edge or API gateway | Implement RFC 9421 verification, key fetching and caching, nonce storage and policy mapping | Retailers with their own edge stack or strict requirements |
| Hybrid | CDN verifies Web Bot Auth; your checkout service additionally verifies Trusted Agent Protocol objects for payment | Retailers taking agent payments |
If you do build it, the verification itself is short. The hard parts are around it: rebuilding the signature base byte for byte, caching keys safely, storing nonces, and deciding what each verified identity may do. A simplified Node.js core shows the shape.
// Simplified: verify an Ed25519 Web Bot Auth signature (no error handling)
import { createPublicKey, verify } from 'node:crypto';
async function verifyAgent(req, keyCache) {
const params = parseSignatureInput(req.headers['signature-input']); // RFC 8941 structured field
const now = Math.floor(Date.now() / 1000);
if (params.tag !== 'web-bot-auth' || params.created > now || params.expires < now) return { ok: false };
const origin = parseSignatureAgent(req.headers['signature-agent']);
const jwk = await keyCache.get(origin, params.keyid); // from /.well-known/http-message-signatures-directory
const base = buildSignatureBase(req, params); // byte-exact per RFC 9421
const sig = parseSignature(req.headers['signature'], params.label);
const ok = verify(null, Buffer.from(base), createPublicKey({ key: jwk, format: 'jwk' }), sig);
return { ok, agent: origin, keyid: params.keyid }; // then: map to a policy tier
}Use a maintained library for the structured-field parsing and signature base construction rather than hand-rolling them; most interoperability bugs live there.
The policy layer
Verification produces an identity. Policy turns it into a decision. I would define four tiers and keep the mapping in configuration, not code:
| Tier | Who | Allowed |
|---|---|---|
| Partner | Verified agents with a commercial or protocol agreement | Search, quote and checkout; agreed rate limits; agent-specific fraud rules |
| Verified | Verified agents without an agreement | Read products and offers; checkout hands back to your own pages |
| Unverified | Unsigned automation that behaves reasonably | Public pages at a sustainable rate; nothing behind a login or cart |
| Denied | Failed signatures, scrapers, abusive patterns | Nothing; logged for review |
Separate tiers for browsing and buying are where the Trusted Agent Protocol’s two tags earn their keep: an agent may be allowed to read freely but need the stronger checkout signature, and a recognised consumer, before it can transact.
A signature tells you who is knocking. Your policy decides whether they come in, and which rooms they can enter.
Abubakr Akhtar
Operating it safely
- 01Log every decision with the agent identity, key ID, tier and outcome. These logs become evidence in disputes and the basis for tuning.
- 02Keep a kill switch per agent that takes effect in seconds, not a deployment.
- 03Short key cache lifetimes (minutes, not days), because removing a key from the agent’s directory is the only revocation available.
- 04Store nonces for at least the validity window to block replays.
- 05Measure, do not just block. Report verified agent traffic, conversions and blocked attempts by agent. This is the data that tells you which platforms matter.
- 06Decide crawling separately. Agents shopping for a customer and crawlers collecting training data are different things with different settings. Make the choice per crawler.
Verified agents still need something to buy and a way to pay. Those layers are covered in ACP vs UCP and agentic payments explained, and being recommended in the first place in generative engine optimisation for ecommerce.
About the author
Abubakr Akhtar
Enterprise business development & partnerships
Abubakr Akhtar is a technology expert who has worked with global companies on martech and solutions.
LinkedInFrequently asked questions
Web Bot Auth is an IETF draft that lets automated clients, including AI agents, sign HTTP requests so websites can verify who sent them. It is a profile of HTTP Message Signatures (RFC 9421), with public keys published in a well-known directory.
It is Visa’s framework for merchants to recognise trusted AI agents and transact with them. It uses signed requests with separate tags for browsing and checkout, an eight-minute validity window and a nonce, plus signed objects for consumer recognition and payment.
No. It proves which operator signed the request. Whether to serve it, and what it may do, depends on your own access policy.
Blocking all automation makes you invisible to customers who shop through agents. A tiered policy based on verified identity keeps the benefit while limiting scraping and fraud.
Ready to put AI to work in your business? Let's talk.
Book a free 30-minute introduction call with our team. No obligation.
- IETF: RFC 9421, HTTP Message Signatures (February 2024)
- PPC Land: Web Bot Auth and the IETF working group (2026)
- Visa Developer: Trusted Agent Protocol merchant specifications
- Visa: Trusted Agent Protocol reference implementation (GitHub)
- Cloudflare Docs: Signed agents
- The Paypers: Visa expands agentic commerce access across Europe (July 2026)
- Mastercard: Mastercard unveils Agent Pay (April 2025)
