An AI agent can now prove who it is. Does your site let it in?

ChatGPT's agent signs its requests, so your bot protection can check who it is. Before that it had a name anyone can copy, or an address list that only the biggest operators publish. On Cloudflare, the challenge wall skips verified agents unless a bot setting or an AI bot policy says otherwise. fetchcheck shows you what your site does with a signed request.

What your bot protection has to go onweakest to strongest

What the agent showsWho can check itWho carries it today

1 A name it typesThe user-agent string. Anyone can copy it. No one. A name can't be checked. Every crawler, real or fake

2 An address on a listIP ranges the operator publishes. Your firewall, against the list OpenAI's crawlers (GPTBot, OAI-SearchBot, ChatGPT-User), Anthropic's ClaudeBot, Perplexity's

3 A signed requestWeb Bot Auth. A signature on every request, checked against the operator's public keys. Your firewall or CDN, on each request ChatGPT's agent. Google-Agent on some requests, marked experimental. Browser services: Browserbase, Anchor Browser, Amazon Bedrock AgentCore. SitedexBot. fetchcheck tests

4 A registered nameANS. A name in a public registry, backed by a certificate. Built for agents calling other agents. Anyone, from the public log. SitedexBot and a few dozen others fetchcheck tests

What your bot protection does with it today

When Amazon barred Meta's Muse agent in September, one of its reasons was that Muse didn't identify itself as an AI agent while browsing (Tech Times). That is the gap a signed request closes: the agent says who it is on every request, and your site can check. In July we sent a crawler that identifies itself and signs every request to 2,684 top sites whose robots.txt welcomes it. It is not on Cloudflare's verified-bot list, which is how a new agent arrives at your site. 1 in 11 refused or challenged it. Among stores, 1 in 5. A challenge fires on reputation: a crawler Cloudflare has not verified gets the same prove-you're-human page whether it signs or not. ChatGPT's agent is verified, and Cloudflare keeps verified bots out of challenges by default on all plans. So the July number is what a new agent gets, and the question for your site is whether that default is still in place.

Paste your URL, pick an identity

fetchcheck has two modes. Web Bot Auth sends a signed request to your site and reports what came back. ANS presents our registered identity and reports whether your site asks for a client certificate.

Web Bot Auth www.lego.com Challenged by bot protection Your site returned a challenge instead of the page (cf-mitigated: challenge, a 403 response). A challenge is meant to stop automated traffic by asking it to prove it is a real browser.

ANS github.com No client certificate required This endpoint answered a request with no client certificate, and answered the one that carried ours. So it doesn't require a client certificate to let a crawler in. That's the normal setup for a public site. Nothing to fix here.

What to change, and where

On Cloudflare's Pro or Business plan: Security, then Settings, filter by Bot traffic, open Super Bot Fight Mode, and set Verified bots to Allow. That lets in the agents on Cloudflare's list: ChatGPT's agent by its signature, OpenAI's crawlers by their published addresses. On the same Settings page, open AI bot policies and check that Agent and Search are not set to Block, because a block there wins over the allow. Since September 15, a new Cloudflare domain blocks Agent on pages that display ads by default (Cloudflare's changelog), so on a newer domain check that Agent isn't blocked on the pages agents need. On Enterprise, the same thing is a custom rule on cf.bot_management.verified_bot.

The fetchcheck re-check stays red after that, because SitedexBot isn't on Cloudflare's list yet. That red is about fetchcheck's own request. The report's page reads reach your site under Cloudflare's own verified identity, listed as Cloudflare Browser Run in your bot analytics, so the Verified bots setting above is what lets the report in. To clear fetchcheck too, on Pro and Business add a custom rule that skips Super Bot Fight Mode for the SitedexBot user-agent. The exact string is at sitedex.dev/bot. On the Free plan, Bot Fight Mode can't be skipped by custom rules, so the options are to turn it off or move to Pro. On other providers, allowlist the same identity. Akamai says it verifies these signatures too.

Where the registered name comes from

Rung 4 is GoDaddy's Agent Name Service, built because a site has had no way to tell a legitimate agent from a copied name. Amazon's complaint about Muse is exactly that. On October 2, 2025 GoDaddy wrote that "there is currently no standard for distinguishing legitimate agents from unvetted or malicious ones" (press release).

An agent gets a name like ans://v1.0.0.bot.sitedex.dev, tied to a domain whose ownership was verified. GoDaddy issues a certificate carrying that name and seals the registration in a public log anyone can read without a login and nobody can edit afterward. The agent can present that identity in the TLS handshake, as a client certificate (mTLS), or, since September, as a signed proof in an HTTP header (DPoP) that gets through a CDN or proxy ending the TLS connection in front of your server, where the handshake method stops (the ANS spec). Either way the receiver checks it against the public log.

fetchcheck's ANS mode presents our registered identity and reports whether your site asks for a client certificate and what it does with ours. Most public sites don't ask, and a site behind a CDN never sees the handshake, the gap the header method fills. We registered SitedexBot on August 31 so the requests we sign ourselves, fetchcheck's included, can prove who sent them. Our first certificate came back without its name; GoDaddy acknowledged our report the same day and fixed it two days later.

ans://v1.0.0.bot.sitedex.dev StatusActiveRegistryGoDaddy ANS, public logLog entry199,562RegisteredAug 31, 2026 transparency.ans.godaddy.com/v1/agents/041f3427-70b2-4902-b6f3-d0f71d507db9

Aug 21Our first identity certificate came back without its ans:// name. Aug 24Reported to GoDaddy. Acknowledged the same day. Aug 26A fresh certificate carried the name. Aug 31Registered and sealed in the public log.

What to do this week

Run fetchcheck on your homepage in Web Bot Auth mode. If the card says "Reachable, content served", you're through gate 1. If it says challenged or blocked, make the changes above and re-check. Then run the full report, because getting in is gate 1 of 3.

Check your site with fetchcheck →

Already through the door? Run the full report.