- One observer's decoy log shows a single Google Cloud address sending 66 requests in 12 seconds under about 25 different AI and search bot names.
- The names were self-declared and did not match the real companies' address ranges, so a list that trusts names alone can be fooled.
- Check how your site decides which AI crawlers to admit, and verify them by network address, not by name.
A name tag anyone can write
When a visitor reaches your website, it announces itself with a short text label. That label is called the user agent. The visitor writes it. Nobody checks it. A crawler can call itself GPTBot as easily as it can call itself anything else.
That matters more now. Many sites choose to welcome AI crawlers, because companies want to appear in AI search results. If the welcome depends on the label, anyone can claim it. The lesson here is that a name is a claim, not an identity.
What the decoy log recorded
The account comes from a Reddit r/cybersecurity thread. Its author says they plant bait files on a handful of small websites and record every visitor that asks for them. This is one person's log from a small set of sites. It is not a survey, and WebPulse has not verified it independently.
The poster says a single Google Cloud address sent 66 requests within 12 seconds on October 25. Nearly every request carried a different bot label. The list reads like a who's who of the AI and search world: OpenAI's GPTBot and OAI-SearchBot, Anthropic's ClaudeBot, Perplexity's crawler, Grok and DeepSeek names, plus the search names Googlebot, bingbot and CCBot. Sixteen further names bring the total to 25.
Each name asked for a different .env path, such as /ai/.env, /llm/.env and /agents/.env. A .env file is where many applications keep passwords and access keys, which is why scanners hunt for it. The poster also notes variants with a Windows data-stream suffix (::$DATA) and dot-dot path tricks. Filters that only match the plain path are the likely target of those variants.
The poster says none of the requests came from the real companies' address ranges.
Why a scanner would dress up as an AI bot
The poster's explanation is a guess, and it is labelled as one. In their view, the scanner may be trying to get past sites that admit AI crawlers by user agent, so those sites can appear in AI search. The post does not say who runs the scanner or whether any real site was breached.
The guess is plausible because of the incentive it describes. A rule that says "let GPTBot through" creates a reason to imitate GPTBot. The same openness that helps a business get found by AI systems also gives attackers a costume.
How the poster caught it
The setup matters, because it shows the check that works. The poster's sites serve fake versions of files scanners look for, including .env, .git/config, cloud key files, and .cursor and .claude configuration files. Real visitors never see them. Crawlers verified by network address and reverse DNS, not by label, get a plain 404 error.
Reverse DNS asks the network which company owns the address a request came from. A real search company's crawler resolves back to that company. A scanner on a cloud provider does not. So every request that reaches a decoy is, in the poster's words, from someone who should not be there.
The poster adds that the scanner's address was then blocked for logins and forms across every site running the same open-source tool, called agentdecoy. The poster promotes agentdecoy, so treat the setup as the poster's own account.
In a reply, the poster added that a decoy has a second use. They said one visitor took a fake cloud key and used it 2 hours 39 minutes later to try to make itself an administrator. This was a separate, unspecified incident. The source does not tie it to the 25-name scanner. A block stops a request. A decoy shows what comes next.
What leaders should ask their teams
None of this requires a decoy system. It requires knowing how your site decides who counts as a trusted AI crawler.
Ask whether any rule admits, exempts or rate-limits traffic based on the user agent alone. If so, ask who verifies that traffic by network address. The poster's own advice is to verify AI bots by address or reverse DNS, not by the label.
Ask whether your logs can show requests that claim to be one bot but come from outside that company's published ranges. Ask whether files such as .env, .git and backup archives are blocked at the web server, so a path trick does not get past a filter.
One log from one observer is a data point, not a trend. But the check is cheap, and the failure it describes is simple. A site that trusts a name tag has handed its door to whoever writes the best one.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Reddit (/u/KnowledgeOk7634).
