Best Web Bot Auth Setup for Merchants Accepting Agentic Checkout

Short answer: verify at the edge, do not gate on it, and split your traffic into three tiers rather than two. Turn on your CDN's signed-bot signal, give verified agents from operators you recognise normal or elevated limits, give verified agents you do not recognise a reduced but usable allowance, and reserve the strict bucket for automated traffic that will not identify itself at all. Log which operator every verified request came from. Blocking unsigned traffic outright is the mistake most teams make first, because as of today the majority of AI operators still do not publish a signing key.

That last point is the one that decides your policy. We checked more than twenty major AI operator hostnames on September 1, 2026 and only four served a valid key directory at the conventional path. If you make a signature mandatory this quarter, you will block real buyers. The full probe results and the protocol mechanics are in our reference page on Web Bot Auth and RFC 9421 HTTP message signatures.

What Shopify's May 2026 change actually did to your traffic

On May 30, 2026 Shopify's developer changelog told bots and agents to identify themselves via Web Bot Auth and said that agents which do not sign are subject to the strictest rate limits on the Storefront API and on Shopify-hosted online store pages. Nothing was blocked. Something more useful happened: unsigned agent traffic got priced the same as anonymous scraping.

That is the model spreading across the platforms that hold checkout. Cloudflare did the same thing earlier, adding message signatures to its Verified Bots Program on July 1, 2025 on the same day it began blocking AI crawlers by default for new zones. AWS WAF followed on November 21, 2025. Three of the largest networks a US merchant sits behind now understand a cryptographic bot identity, and all three implemented it before the IETF adopted a document.

For a merchant the consequence is concrete. You can now serve agent traffic generously without also serving every scraper that sets a user-agent header to something plausible. That was not a choice you had a year ago.

The three tier policy worth copying

Two tiers is the intuitive design and it is wrong, because it forces you to choose between blocking unsigned buyers and treating every signed request as trusted. Three tiers costs nothing extra to configure.

Note what is missing: a block. Unsigned traffic is throttled, not refused. That keeps the door open for the operators who have not shipped signing yet, and it means a key rotation gone wrong degrades a customer's experience instead of ending it.

Best setup if you are already behind Cloudflare

Start here, because it is a configuration change rather than an engineering project. Cloudflare validates signatures at its edge and exposes the outcome to firewall rules through the cf.verified_bot_category field, so your three tiers become three rules. You do not fetch key directories, you do not implement RFC 9421, and you do not have to think about the signature base.

Two things are worth doing beyond the default. First, keep your own list of operators you have deliberately welcomed, rather than treating the whole verified population as one group, because the difference between tier one and tier two is a commercial decision and not a security one. Second, make sure the rule ordering puts your verified-agent rules ahead of any general bot challenge you already run, or you will CAPTCHA the exact traffic you meant to prioritise.

Best setup if you are on AWS WAF

AWS published the clearest model of how verification should behave when things go wrong, and it is worth copying even if you never touch AWS. Rather than returning a boolean, AWS WAF polls registered operator key directories and labels each request as verified, invalid, expired or unknown_bot. Verified Web Bot Auth traffic is allowed by default in Bot Control.

Those four states matter because collapsing them into pass or fail is how teams end up throttling a partner over a routine key rotation. An expired label is not an attack, it is a calendar problem at the other end. An invalid label is genuinely suspicious and deserves a different rule. Treat them differently and your logs will tell you which is which at 2am.

Best setup if you verify at your own origin

If you are terminating this yourself, use a library instead of building the signature base by hand, since that is where the subtle interoperability bugs live. Cloudflare publishes a Rust crate and a TypeScript npm package, both named web-bot-auth. Beyond that, four rules keep a homegrown verifier honest:

1. Resolve the key by keyid, which is the base64url SHA-256 thumbprint of the JWK, and cache the directory with a short TTL rather than indefinitely.
2. Honour expires and reject anything outside the window. OpenAI's published ChatGPT key carries a hard expiry, so keys demonstrably do rotate.
3. Require that Signature-Agent, if present, is itself covered by the signature. Otherwise an attacker can point you at a key directory they control.
4. Enforce the nonce window so a captured signature cannot be replayed against a different request.

One operational detail that catches people: the key directory is an upstream dependency you did not choose. If an operator's endpoint goes dark, your verifier fails their traffic closed and the symptom is a quiet revenue dip rather than an error page. Point whatever checks your APIs from multiple locations at the handful of directories you actually depend on, and alert on content type as well as status, because a 200 that returns an HTML app shell is the most common false positive. Both shopify.com and platform.openai.com return exactly that at the well-known path.

Where do I find an operator's Web Bot Auth key?

At /.well-known/http-message-signatures-directory on the hostname the traffic originates from, not the company's corporate domain. This trips up almost everyone building an allowlist for the first time: openai.com returns 404 while chatgpt.com serves a valid single-key directory with the correct application/http-message-signatures-directory+json content type. Check the traffic domain.

Be careful drawing conclusions from a 404, though. Both Cloudflare and AWS let an operator register a key directory at an arbitrary URL when they sign up, so the well-known path is a convention rather than a requirement. An operator can be fully verified at the edge and still return nothing at the conventional location.

What to log, and why finance will ask for it

Log the verification state and the operator identity on every request, not just on the ones you throttle. The moment an agent-placed order gets disputed, the question is not whether the request was signed, it is which operator signed it and under which key. That record is the merchant-side half of the same accountability chain a buyer builds with an immutable audit trail on their end, and neither half is much use alone.

This also turns into a commercial dataset faster than people expect. Once you can attribute orders to agent operators, you can see which agent products actually convert on your catalog, and that is the input to every decision you will make about agentic commerce protocol support, feed formats and which platforms deserve engineering time. Merchants who only recorded a boolean spent 2026 unable to answer basic questions about a growing share of their revenue.

Where verification stops helping

A validated signature tells you an agent genuinely belongs to the operator it names. It tells you nothing about whether the purchase was authorized by the person the agent is acting for, whether it fits a budget, or whether the same agent is placing the same order at nine other merchants right now. Those are different questions handled at different layers.

The payment protocols are building on top of this floor rather than replacing it. The Visa Trusted Agent Protocol uses the same RFC 9421 mechanism and adds tag values that separate an agent that is browsing from one carrying a consumer-authorized payment instruction. AP2 handles the proof that a human approved a specific purchase. If you are working out which of these to support and in what order, our breakdown of agentic checkout for merchants covers the commercial side, and shopping agents covers what changes in the order flow itself.

A short checklist

1. Turn on the signed-bot signal at your CDN and confirm you can see the label in logs before you write a single rule.
2. Write three rules, not two. Never make signing mandatory this year.
3. Order verified-agent rules ahead of any existing bot challenge.
4. Distinguish expired from invalid. They mean different things and deserve different responses.
5. Log the operator on every request, forever.
6. Monitor the key directories you depend on, including their content type.
7. Revisit the operator list quarterly. The population of agents that sign is growing fast and your tier one list will be stale within a quarter.

None of this decides what an agent is allowed to spend, which is the other side of the same transaction. If you are the one deploying agents rather than selling to them, that control belongs in a policy layer above the payment rail, and signing your own traffic makes having one more urgent, not less.