We finally opened Cloudflare's AI Crawl Control last week, mostly out of curiosity about which AI bots actually visit us. It had been collecting quietly the whole time. The first 24-hour window we looked at showed 1,890 requests from AI agents, and 483 of them failed. Compared with the previous day, that failure count was up 63 percent.
The worst record belonged to the agent we were most curious about. ChatGPT-User is the one OpenAI documents as user-initiated: it visits a page when someone asks ChatGPT or a Custom GPT a question, rather than crawling on a schedule. It accounted for 859 requests. Only 412 came back 200.
So roughly half the requests wearing that name were bouncing. I wrote it up as a redirect problem: we had migrated docs slugs more than once, so stale URLs would explain it, and a redirect map would fix it. Clean story. It was wrong.
Then I looked at the actual paths.
/id_rsa
/terraform.tfstate
/.env.prod.bak
/elmah.axd
/@fs/proc/self/environ
/.github/workflows/deploy.yml
/.claude/settings.json
/api/config
That is not a stale sitemap. That is a vulnerability scanner's shopping list: SSH keys, Terraform state, environment backups, CI configuration, framework-specific leak paths. Of the 483 failures, 447 were this shape, and all 447 carried the ChatGPT-User user agent.
Every probe got a 404. Nothing was exposed. As internet background noise this is unremarkable; any public site gets it hourly. What made it interesting is the channel.
First lesson: the aggregate lied. "Unsuccessful requests, up 63 percent" reads like a site problem, and I very nearly shipped a redirect map to fix a scanner. The rate told me nothing. The paths told me everything.
Second lesson, the one I had to be corrected on: the label lied too. I wrote a first draft of this that called the remaining 412 requests genuine fetches, which was a claim I had no basis for. On the free plan, Cloudflare's AI Crawl Control identifies AI agents by their user agent string. Its own documentation says so: "On the free plan, AI Crawl Control identifies AI crawlers based on their user agent strings." A user agent is a string the client chose to send. It is not evidence of who sent it.
So the honest version of my own finding is narrower than the version I liked: 859 requests claimed to be ChatGPT-User, 447 of them were scanning for secrets, and 412 got 200s. Whether any of them came from OpenAI is a separate question that a user-agent label cannot answer.
If you want to answer it, two things are available without an enterprise plan. OpenAI publishes per-agent IP ranges, including one specifically for this agent at openai.com/chatgpt-user.json, so you can check an address against the published list. And Cloudflare exposes cf.client.bot in WAF custom rules on every plan, which carries the same verified-bot signal as the enterprise field; a rule shaped like http.user_agent contains "ChatGPT-User" and not cf.client.bot separates verified traffic from traffic that merely claims the name. The stronger cf.bot_management.verified_bot and detection IDs need Enterprise with Bot Management, which is what I had assumed we were looking at and were not.
One last correction worth passing on, because I had this backwards too. A ChatGPT-User hit in your logs is not the assistant reading your page for the person currently asking. Research published this month found ChatGPT serves opened pages from a shared cache, keyed on the URL rather than the user, so one account's copy gets served to another account in another country with no request reaching your server at all. What you see in your logs is a refresh for whoever comes next.
Which leaves a tidier summary than the one I started with. We looked at an alarming AI metric, started fixing AI discoverability, and found that most of the traffic was security scanning wearing a familiar name.
Disclosure: I build Mnemoverse, a memory engine for AI agents, so this came out of watching our own traffic rather than a security engagement.
