Why AI shopping agents get a 403 at your checkout

A customer asks an AI assistant to buy a pair of running shoes. The assistant finds your store, opens the product, adds it to the basket, and heads to checkout. Your store answers with 403 Forbidden. The assistant tells the customer the item "couldn't be purchased right now" and offers a competitor's instead.

Nobody on your team sees this happen. There is no abandoned-cart email, because there was never a session. There is no error in your storefront logs, because the request never reached your storefront. The only trace is a line in your CDN or bot manager's logs, filed under traffic it was told to stop.

This post explains why that happens, how to check whether it is happening to you, and how to fix it in each of the major bot managers without letting scrapers back in.

What does a 403 from your store mean to an AI agent?#

A 403 tells an agent that your store refused it, and almost every agent treats that as final. It does not retry with different headers or wait for a human to solve a puzzle. It moves on.

A person who hits a block can refresh, switch networks, or tick a CAPTCHA. An AI shopping agent is acting for someone who is not watching. When it is refused, it has three options: give up, try a different store, or tell the shopper the product is unavailable. All three lose you the sale.

The refusal does not have to be a literal 403. Bot managers also answer with an interstitial "checking your browser" page, a JavaScript challenge, a CAPTCHA, or a 429 rate-limit response. To an agent they all mean the same thing: this store will not let me in.

Why does bot management block AI shopping agents?#

Because to a bot manager, an AI agent looks exactly like the automation it was bought to stop. The signals these products use to separate people from bots all point the wrong way for an agent acting legitimately for a customer.

• It says who it is in a header anyone can forge. The User-Agent string is free text. Scrapers have been copying browser and well-known bot user agents for years, so bot managers rightly give it little weight on its own.
• It arrives from cloud infrastructure. Agents run in data centres, not on home broadband. IP reputation scoring treats data-centre ranges as higher risk.
• It does not carry the bot manager's cookies or telemetry. Many products set a cookie with a JavaScript sensor on the first page and expect it on every request after. An agent that fetches a product page directly, or uses a headless browser, often has none of it.
• Defaults lean towards blocking. DataDome, for example, documents that "any automated request coming from an unauthenticated bot or AI agent is categorized as 'Threat Detection' and is blocked by default." Other products are similar unless someone has configured an exception.
• Checkout is protected harder than the catalogue. Card-testing and account-takeover attacks target cart, checkout and login, so those paths get the strictest rules. That is exactly where an agent needs to go.

The result is a store that is open to agents on the home page, partly open on product pages, and closed at the basket. The free robots.txt file may even say agents are welcome. Robots rules are a request about crawling; a bot manager enforces its own policy regardless of what robots.txt says.

Replay

How do signed agents prove who they are?#

A signed agent attaches a cryptographic signature to each request, and publishes the public key that verifies it. A bot manager no longer has to guess from the user agent and the IP address. It can check.

The mechanism is HTTP Message Signatures, standardised as RFC 9421 in 2024, applied to bots by a profile known as Web Bot Auth. A signed request carries three headers:

Signature-Agent: sig1="https://chatgpt.com"
Signature-Input: sig1=("@authority" "signature-agent";key="sig1");created=1760000000;expires=1760000300;keyid="…";tag="web-bot-auth"
Signature: sig1=:MEUCIQ…:

Signature-Agent names the agent's operator and where its keys live. (Older drafts, and some operators' documentation, write it as a bare string, "https://chatgpt.com"; the current draft requires the labelled form shown here and lets verifiers accept both.) Signature-Input lists which parts of the request are covered and when the signature expires, usually within minutes. Signature is the signature itself. The verifier fetches the operator's key directory from a well-known address on that domain and checks the signature with the public key. A request that forges the header without the private key fails.

Three things make this the practical answer in late 2026:

1. The large agents sign. OpenAI documents that its agent traffic is signed with Web Bot Auth and names https://chatgpt.com as its signature agent. Cloudflare lists ChatGPT's agent among the first signed agents it recognises.
2. The bot managers verify. Cloudflare introduced a "signed agents" classification in August 2025 and, from July 2026, folds signed agents into its verified bots with a field recording whether access is direct or through an intermediary. DataDome verifies Web Bot Auth signatures. OpenAI's own guidance says Akamai needs no additional signature verification once the policy is set, and that Vercel admits the traffic without configuration.
3. The standard is moving through the IETF. The protocol draft, draft-ietf-webbotauth-httpsig-protocol, was adopted by the Web Bot Auth working group and published as a Standards Track draft in September 2026. It is not yet an RFC, so details can still change, but the shape is settled.

How can you tell if your store blocks AI agents?#

Test the paths a purchase takes, as both a signed and an unsigned agent, and read the status code at each step. A home-page check is not enough; the blocks that matter are usually at cart and checkout.

Start with your own logs. In your CDN or bot manager, filter for requests that carry a Signature-Agent header or a known agent user agent, and look at the action taken. If you see blocks, challenges or 403s on /cart, /checkout or your cart API, agents are being turned away.

You can reproduce the unsigned case from a terminal. This only shows what happens to an agent that identifies itself by user agent alone, which is still how many agents arrive:

# What does your checkout answer to a request that only claims to be an agent?
curl -s -o /dev/null -w "%{http_code}\n" \
  -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot" \
  https://your-store.example/cart

A 200 means the request reached the page. A 403, a 429, or a 200 whose body is a "checking your browser" page means a rule refused it. Repeat for a product page, the cart, and the first checkout step.

The signed case is harder to test by hand, because you need a key whose directory your bot manager will fetch. This is what tragent's scan does for you: it requests each stage of the purchase path twice, once with a Web Bot Auth-signed agent and once unsigned, and reports where each was refused and which bot manager refused it. tragent's public keys are published at tragent.io/.well-known/http-message-signatures-directory, so your security team can verify any request we send.

Two results deserve particular attention:

• A signed agent refused. This is the costliest failure, because it turns away the agents most likely to be sent by real shoppers. tragent reports it as An agent that proved who it was is refused.
• An unsigned copy admitted where the signed one is not. If a request that merely claims to be an agent gets further than one that proves it, your rules are trusting the user-agent string. That is backwards, and it is a door for scrapers. See An unproven copycat is let in.

How do you fix it in each bot manager?#

Allow verified agents first, before any rule that challenges automation, and scope the exception to the paths a shopper needs. The exact place differs by product. What follows is where the refusing rule usually lives; your configuration may differ, so check the rule your logs name.

Cloudflare#

On Cloudflare, WAF custom rules run before Super Bot Fight Mode, so an exception placed there wins. In Security → WAF → Custom rules, add a rule that matches verified bot traffic and uses the Skip action for the bot phases, and place it above any rule that challenges on bot score. If you write rules on cf.bot_management.score, add an exception for cf.bot_management.verified_bot to each one.

If you are on Super Bot Fight Mode without Bot Management, the settings are coarser: you choose an action for Definitely automated and Likely automated traffic as a whole. If those are set to block or challenge, a Skip rule scoped to your product, cart and checkout paths is the narrowest way to let verified agents through. Our fix page for a verified agent that was blocked walks through it.

Akamai#

In Bot Manager, open the Akamai-categorised bots and find the AI assistant and agent categories. Set their action on your product, cart and checkout endpoints to Allow or Monitor, not Deny or Tarpit. Then review the transactional endpoint protection on your checkout URL: it often denies any request without the sensor cookie, which an agent will not have.

DataDome, HUMAN, Imperva and Kasada#

The pattern is the same. Find the policy that applies to unauthenticated automation on your commerce paths, and add an allow rule for authenticated agents above it. Prefer verification by signature or by the operator's published identity over a user-agent match; a user-agent rule lets anyone through who types the right string.

If a CAPTCHA is in the way#

A CAPTCHA on browsing, the basket or checkout stops every agent, signed or not, because solving it is exactly what an agent cannot do for a customer. Keep CAPTCHAs for actions that attract abuse, such as sign-up and password reset, and exempt verified agents everywhere a purchase happens. tragent reports this as Checkout needs a CAPTCHA only a person can pass.

How do you let agents in without letting scrapers in?#

Admit agents by proof, not by claim, and only where a shopper needs to go. Opening your bot manager wholesale undoes the protection you pay for. A narrow exception keeps it.

1. Verify, do not match strings. Allow requests whose Web Bot Auth signature verifies, or which the bot manager has itself classified as a verified agent. Never allow by User-Agent alone.
2. Scope by path. Agents need product pages, search, the basket, checkout, and order status. They do not need your admin, your account-creation flow, or bulk catalogue endpoints.
3. Keep rate limits. A verified agent shopping for one person makes a handful of requests. Rate limits that stop a scrape at thousands of requests a minute will not touch it.
4. Keep fraud controls on payment. An agent paying with a delegated card still goes through your payment provider's checks. Nothing about admitting it should weaken those.
5. Decide which agents you want. Signed identity means you can choose. You might admit the assistants your customers use and continue to block training crawlers, which is a separate decision about your content.

What should you check after the fix?#

Re-run the same test, signed and unsigned, on every stage of the purchase, and keep running it. Bot rules drift. A new rule added after a card-testing attack, a vendor default changed in an update, or a migration to a new CDN can close the door again without anyone noticing.

After the change, confirm three things:

• A signed agent reaches the product page, the basket and the first checkout step with a 200 and real content, not a challenge page.
• An unsigned request that only claims to be an agent is treated no better than before.
• Your bot manager's logs show the verified-agent exception matching, not a broader rule.

Then make it part of your release process. A bot rule is configuration like any other, and a change that blocks agents at checkout should fail the build the way a broken checkout button would. Our guide to continuous testing shows how to gate deploys on it.

Frequently asked questions

Does robots.txt control whether AI shopping agents can buy from my store?

No. robots.txt asks crawlers which paths not to fetch; it does not enforce anything. A bot manager or firewall enforces its own policy, so a store can allow agents in robots.txt and still block them at checkout.

Should I allow AI agents by user agent?

No. The User-Agent header is free text that anyone can copy. Allow agents whose Web Bot Auth signature verifies, or that your bot manager classifies as verified, and scope the exception to commerce paths.

Which AI agents sign their requests?

OpenAI documents that its agent traffic is signed with Web Bot Auth, naming https://chatgpt.com as its signature agent. Cloudflare's directory lists other signed agents, and more operators are adopting the standard as it moves through the IETF.

Will allowing signed agents let scrapers in?

Not if you allow by verified signature rather than by user agent. A scraper cannot produce a valid signature for another operator's key, so a verified-agent exception admits only the operators you choose.

Why does my store work for agents on the home page but not at checkout?

Bot managers usually apply their strictest rules to cart, checkout and login, because those are the targets of card testing and account takeover. Test every stage of the purchase, not just the first page.

Sources

1. RFC 9421: HTTP Message Signatures — IETF
2. HTTP Message Signatures for Bots (draft-ietf-webbotauth-httpsig-protocol) — IETF Web Bot Auth working group. Internet-Draft, September 2026
3. ChatGPT agent allowlisting — OpenAI Help Center
4. The age of agents: cryptographically recognizing agent traffic — Cloudflare blog. August 2025
5. Verified bots — Cloudflare docs. Includes the July 2026 classification change
6. Super Bot Fight Mode — Cloudflare docs
7. Bot authentication — DataDome docs

Written by the tragent team and checked against the sources listed above on October 19, 2026. See how we write and correct posts in our editorial policy.