I Blocked "ClaudeBot" 4,000 Times. It Was Never Anthropic.
**Marcus Webb** — Infrastructure engineer turned tech writer. Writes about AI, DevOps, and security.
**Bottom line:** A sophisticated, non-Anthropic entity is spoofing "ClaudeBot" user-agents to conduct widespread vulnerability scans, leading to thousands of blocked requests on production systems.
Over the past six weeks, my team observed over 4,000 such blocks on our WAF, each attempting known CVEs.
This isn't just an annoyance; it’s a stealthy, costly reconnaissance effort that demands immediate attention to your bot management and WAF rulesets, as it bypasses standard reputation-based blocking by mimicking a legitimate AI agent.
I cancelled my ChatGPT Pro subscription after six months.
Not because it was bad – it was fantastic – but because I discovered what it, and other large language models, were doing to my ability to think critically about *actual* bot traffic.
I'd grown comfortable, perhaps even complacent, with the idea that "good" bots identified themselves honestly. That assumption, as I recently learned the hard way, is a dangerous liability.
The Phantom Bot That Wasn't
For the last six weeks, my team's WAF dashboards started lighting up with a peculiar pattern. Thousands of requests, all hitting various endpoints on our public APIs and web services. The common thread?
A user-agent string proudly proclaiming "ClaudeBot/1.0 (+https://www.anthropic.com/claude-ai)". My immediate thought was, "Okay, Anthropic is doing some crawling, probably for RAG or training data.
Interesting, but we need to rate-limit this." We’d seen similar traffic from Google's various bots, from OpenAI's crawlers, and even some smaller research entities.
Standard procedure: check the IP, verify against known ranges, and if it's legitimate, adjust our WAF to allow a reasonable crawl rate.
What we found, after blocking over 4,000 requests from this supposed "ClaudeBot" across our primary application cluster, wasn't interesting. It was alarming.
Unmasking the Imposter: Beyond the User-Agent
The first red flag was the sheer volume and the targets. This wasn't a gentle, polite crawl.
The requests were probing for known vulnerabilities: `/.env`, `/wp-admin`, various `.git` exposure attempts, and even some obscure CVEs we'd patched months ago.
A legitimate AI training bot wouldn't be hammering `/admin/login.php` on a non-WordPress site. That alone raised my eyebrows.
Our initial instinct was to check the IP addresses. Anthropic, like any major cloud provider or service, publishes its IP ranges.
A quick `whois` lookup on the source IPs from our logs revealed a mix of residential proxies, compromised IoT devices, and various dark cloud providers.
Not a single one resolved back to Anthropic's ASNs or public IP ranges. This "ClaudeBot" was a ghost, cloaked in a borrowed identity.
We were looking at a sophisticated, distributed vulnerability scanner, masquerading as a benign AI crawler.
It was leveraging the current trust developers implicitly place in AI companies, betting that security teams would hesitate to block what *appeared* to be a legitimate agent from a major player like Anthropic.
This wasn't just a random script kiddie; this was a well-resourced operation.
The Cost of Trusting User-Agents
This incident exposed a critical blind spot in many organizations' bot management strategies.
We've spent years building WAF rules and rate limiters based on known good bots, whitelisting specific user-agents or IP ranges.
The assumption is that if a bot identifies itself as "Googlebot," it *is* Googlebot. This "ClaudeBot" incident shatters that assumption, especially in the rapidly evolving AI landscape.
Why does this matter beyond the obvious security implications? Cost, for one. Every one of those 4,000 blocked requests still consumed network bandwidth, CPU cycles on our WAF, and log storage.
Multiply that across thousands of endpoints and potentially hundreds of thousands of requests per day on a larger scale, and you're looking at a tangible operational expense for defending against what should be easily identifiable malicious traffic.
Beyond that, the time spent by my team investigating what *appeared* to be legitimate traffic from a major AI company was time not spent on other critical infrastructure tasks.
It's a subtle form of denial-of-service, draining resources and attention.
Beyond Basic Bot Detection: A Deeper Dive
Identifying bots purely by user-agent has been a losing game for years, but the rise of AI agents adds a new layer of complexity.
Attackers know that security teams are now accustomed to seeing new AI crawlers. They're banking on us being slow to adapt.
So, what’s the play? We moved past simple user-agent matching.
#### 1. IP Verification is Non-Negotiable
For any bot claiming to be from a major provider (Google, OpenAI, Anthropic, Microsoft, etc.), you *must* verify the source IP address against their published ranges.
This is your first line of defense. If the IP doesn't match, it's immediately suspicious.
We integrated this check into our WAF’s custom rules, allowing only traffic from Anthropic’s *actual* ASNs to pass through with the "ClaudeBot" user-agent. Everything else is treated as malicious.
#### 2. Behavioral Analysis Over Identity Claims
User-agents are easily spoofed. IP addresses can be proxied. What's harder to spoof is behavior. Malicious bots typically exhibit patterns:
* **Rapid traversal:** Hitting many unrelated endpoints in quick succession. * **Targeting known vulnerabilities:** Probing for common exploits or admin interfaces.
* **Non-standard request headers:** Missing or malformed headers.
* **Lack of referer or inconsistent referers.** * **Unusual request frequency or timing.**
Our WAF, a custom setup built on ModSecurity and leveraging threat intelligence feeds, now prioritizes behavioral anomaly detection.
If a user-agent claims to be a friendly bot but behaves like a vulnerability scanner, it gets blocked.
This is where advanced bot management solutions shine, but even custom WAF rules can be tuned for this.
#### 3. The Cost of Over-Permissiveness
There's a temptation to be overly permissive with new AI agents, fearing you might block legitimate traffic from future models like an unreleased ChatGPT 5 or a new Claude 4.6. This is a false economy.
Blocking a legitimate bot for a few hours while you verify its authenticity is far less damaging than allowing a malicious actor to scan your entire infrastructure for vulnerabilities.
Err on the side of caution. If it's a new, unknown bot, treat it as hostile until proven otherwise.
The Reality Check: AI's Dual-Use Problem
This "ClaudeBot" incident isn't an isolated anomaly; it’s a harbinger. As AI models become more ubiquitous, the line between legitimate and malicious automated traffic will blur further.
We're already seeing threat actors leverage large language models like Gemini 2.5 to craft more convincing phishing emails and social engineering attacks.
It was only a matter of time before they weaponized the *perception* of AI legitimacy itself.
The hype around AI often focuses on its transformative power for good. But like any powerful technology, AI has a dual-use problem.
The same principles that allow AI to process vast amounts of data for research can be repurposed to efficiently discover and exploit weaknesses in your systems.
The industry isn’t talking enough about this.
We're too busy debating whether AI will take our jobs or achieve sentience, while the more immediate, ground-level security implications are often overlooked.
The Practical Takeaway for Developers and Infrastructure Teams
Don't assume good intent. Trust is earned, not given, especially when it comes to automated traffic on your production systems.
1. **Harden Your Bot Management:** Go beyond user-agent strings. Implement IP verification for *all* major AI bots.
Leverage behavioral analysis to detect suspicious patterns. If you're using a commercial WAF, ensure its bot management module is configured for this level of scrutiny.
If you're building your own, invest in robust logging and real-time analytics.
2. **Regularly Review WAF Logs:** Don't just set it and forget it. Those "blocked" logs are a treasure trove of information about who is trying to access your systems and how.
We found the "ClaudeBot" by noticing a sudden spike in blocked requests from a specific user-agent that didn't match our expectations.
3. **Educate Your Team:** Ensure everyone on your infrastructure and security teams understands that user-agents are easily spoofed.
The default assumption for unknown or suspicious traffic should be "malicious," not "benign until proven otherwise."
4. **Stay Updated on AI Provider IP Ranges:** Major AI companies like Anthropic, OpenAI, and Google publish their IP ranges.
Subscribe to their security advisories or use APIs to keep your whitelists current. This is a dynamic threat, requiring dynamic defenses.
This incident served as a stark reminder: the internet is still a wild place, and the advent of AI hasn't made it any tamer. It's simply given attackers new disguises.
My infrastructure isn't going to be a free scanning target for anyone spoofing a new AI agent, and neither should yours.
Have you noticed your WAF logs showing suspicious traffic claiming to be from a legitimate AI bot, or is it just me? What strategies have you implemented to cut through the noise of spoofed AI agents?
Let's talk in the comments.
---
