Cequence's threat research group published a report on 28 October 2026 describing one actor that pretended to be about 32 different AI bots, including ChatGPT, Claude and Perplexity crawlers, while requesting files that usually hold secrets. The scanner ignored web pages entirely and asked for .env files, cloud credential files, private SSH keys and server environment data. If you deploy projects, many of them built with coding agents, the fix is not to block "AI bots" but to make sure those files are not reachable in the first place, and to stop treating a claimed bot name as proof of anything.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | Any public web server or API can be probed. You are exposed only if a secret-bearing file is actually served. |
| Is there a fix? | No patch; it is a scanning pattern. The fix is configuration: keep secrets out of the web root and lock down staging and admin sites. |
| Were secrets stolen? | Cequence reports credential-seeking requests, not confirmed theft. |
| Does it exploit a bug in ChatGPT or Claude? | No. The names are just user-agent disguises. |
| How long did it run? | From at least late September through late October 2026, per Cequence. |
What the scanner does
The Cequence post by Will Glazier, Director of CQ Prime Threat Research and Data Science, describes the traffic this way:
- It runs from a major cloud provider and rotates through about 32 AI bot identities spanning crawlers and assistants from OpenAI, Anthropic, Meta, Perplexity and others.
- It works from a list of roughly 90 file paths:
.envconfiguration files, cloud credential files, private SSH keys and server environment data. - Each address sends a short burst of 50 to 190 requests in about eight seconds, then moves on.
- It handles targets one at a time, around the clock. First it sends random nonsense paths to find sites that answer every request with a success code, a common way to avoid false positives.
- It hit financial services, retail, telecommunications, energy and software organizations.
The Cyber Security News write-up summarizes the same findings. Its caveat is the same as Cequence's data: this establishes probing, not a proven breach.
Why the disguise works
Many sites treat well-known AI crawlers specially. Some allow them through rate limits or bot filters; some operators explicitly permit them in robots.txt. Cequence says it is seeing attackers probe which agents a business trusts, then impersonate the agents they expect to get through. The report ties this to a wider trend: banks are deciding which AI agents to let into customer accounts, and each allow or deny decision can be tested by an attacker.
The request pattern also skews metrics. At several organizations, the impersonator accounted for more than 80% of traffic labeled as AI bot traffic. Any dashboard that counts AI bots by self-reported identity may be counting impostors. At the financial organizations Cequence studied, agents acting for real customers were fewer than 1 in 4,000 requests, because those agents log in with the customer's own credentials through an ordinary browser and do not announce themselves. In other words, labeled AI bot traffic shows only the agents that want to be seen.
How Cequence spotted the fakes
The impostors broke patterns real bots follow:
- The scanner cycled evenly through all 32 identities, which no legitimate bot does.
- One machine claimed to be OpenAI, Anthropic, Meta and Perplexity within seconds.
- Its fake Claude identities all carried the contact address of Anthropic's crawler, even when posing as a different Claude agent, which suggests a copied string.
- It never identified itself or offered a contact address, whereas legitimate scanning services publish who they are and where they scan from.
Shared addresses and technical fingerprints across targets tie the activity to a single actor, according to Cequence.
Why IP blocklists fall short
More than 300 cloud addresses appeared in a single day and nearly 400 in a week. None from late September came back a month later. Third-party threat feeds flagged many of the addresses during the same days they were used against Cequence customers, but the scanner had usually moved on. The behavior stayed consistent, which is why Cequence argues for behavior-based detection over static address lists.
What is confirmed and what is not
Reading a vendor's own telemetry calls for care, so here is the split.
Reported by Cequence, from its own customer traffic: the roughly 32 rotating identities, the 90-path list, the 50 to 190 request bursts, the cloud-hosted infrastructure, the activity window from late September to late October, and the 48% figure. That last number means the actor reached 48% of the Cequence-protected organizations that saw any AI bot traffic on one October day. It is not 48% of all websites, and it is not a measure of how many were compromised.
Not established: who runs the scanner, whether any credential was obtained from an unprotected site, and what the actor did with any result. The report names no group and no downstream breach, and we found no independent confirmation from another vendor at the time of writing. The sector list (financial services, retail, telecommunications, energy, software) describes who Cequence protects as much as who was targeted, since the data comes from its customer base.
Also worth keeping straight: none of OpenAI, Anthropic, Meta or Perplexity is accused of anything. Their bot names were borrowed. The Claude identities reusing Anthropic's crawler contact address is, per Cequence, evidence of copying.
A practical log check
If you run your own web server, a quick pass takes minutes:
- Pull a week of access logs and filter for requests whose path contains
.env,.aws,.ssh,id_rsaor.git/config. - Group by client address and count requests per address per minute. A burst of dozens in a few seconds from one address matches the reported 50 to 190 requests in about eight seconds.
- Compare the user-agent strings to the address owner. A client that claims to be a major AI crawler but originates from a generic cloud range, and that cycles through different vendor names, is a mismatch of the kind Cequence describes.
- Look at the response codes. A 404 or 403 means nothing was served. A 200 on any secret-bearing path means you should treat that file's contents as exposed and rotate.
- Remember the decoy step: the actor first requests random nonsense paths. If your server answers those with a 200 (a catch-all route in a single-page app, for example), your logs will show success codes that are not real files. Check the response body size before panicking, but also fix the catch-all so it returns 404 for missing paths.
What this means if you run AI coding agents
You may never run a public crawler, yet this campaign touches your workflow in three ways.
1. Check what your deployed folder serves. Coding agents scaffold projects quickly, and a .env, a .git directory or a backup can end up in a static export or a container image. From outside your network, request the common paths on your own sites (for example /.env) and confirm you get a 404 or 403. Do the same for staging and admin sites, which Cequence specifically says should not be internet-exposed.
2. Keep secrets out of web-accessible files. Load them from the platform's secret store or the process environment, not from files under the document root. Our guide on how API keys leak through logs and environment variables covers the common paths.
3. Search your access logs for the pattern. Look for a single client touching .env, .aws/credentials, id_rsa or similar paths in a burst of dozens of requests within seconds, especially with user agents naming AI services. Then check whether any of those requests returned 200. If one did, rotate the credentials in that file immediately, as in our runbook for the first 24 hours after a vendor breach.
4. If you do allow AI crawlers or agents, verify them. Use signed requests, published address ranges or direct integrations, as Cequence recommends, rather than the user-agent string. A rule like "allow anything that says ClaudeBot" is equivalent to allowing anyone.
Related reading on the agent side: US banks block AI agents from customer credentials, and Wiz's account of agentic attacks and their fingerprints.
What Beam can and cannot do here
Beam does not sit in front of your web server and cannot block or classify inbound HTTP traffic; use a web application firewall or bot management for that. What it does on the developer's machine is watch what Claude Code, Codex and similar agents run and flag risky actions such as credential exposure, and it keeps that data local (see what Beam watches). That helps with the upstream cause: an agent that copies a .env into a build output or prints a key into a log is the kind of event worth catching before it reaches a public server. The limits are plain: detection is heuristic, deny is hook-based for Claude Code and Codex rather than a kernel sandbox, and Beam cannot tell you what your deployed server serves.
Frequently asked questions
What did Cequence find?
Cequence's CQ Prime team tracked a single actor that posed as about 32 AI bots, including ones tied to OpenAI, Anthropic, Meta and Perplexity, while requesting around 90 file paths that commonly hold secrets, such as .env files, cloud credential files and private SSH keys.
Were credentials actually stolen?
The research establishes credential-seeking requests, not confirmed theft or follow-on compromise. Cequence says nearly all of the actor's requests ended in a block or failure on its protected sites, but a site that serves such a file would hand it over.
How can I tell a real AI crawler from a fake one?
Do not trust the user-agent string. Cequence recommends verifying through signed requests, published address ranges or direct integrations, and watching for behavior that does not match the claim, such as an assistant requesting configuration or credential files.
Will blocking the IP addresses work?
Not for long. The actor used more than 300 cloud addresses in one day and nearly 400 in one week, and none of the addresses seen in late September reappeared a month later.
Does this affect people who use coding agents?
Indirectly. Projects built with coding agents often ship .env files, staging sites and admin panels, and a deployed folder that exposes them is exactly what this scanner probes. Check what your web root serves.
Related reading
- API keys in logs and env vars: how they leak
- US banks block AI agents from customer credentials
- Wiz: seven fingerprints of agentic attacks
- VOLTA infostealer ranks victims by SSH keys and cloud configs
Details are accurate as of November 2, 2026, and are based on the Cequence CQ Prime report and press coverage. Beam is a local prototype, and Cequence may update its findings after publication.