Cequence says one scanner posed as about 32 AI bots, ChatGPT and Claude among them, to hunt .env and SSH keys

Six to 24 requests a second from one address, and no list of what they asked for

Cequence's post gives three figures that fit together. Each address sent a burst of 50 to 190 requests in about eight seconds. The scanner worked from a list of roughly 90 file paths. And it rotated through about 32 bot identities. That is about 6 to 24 requests a second from a single address (derived from the burst figures). Cequence also says the actor used more than 300 cloud addresses in one day, so on that day the scanner sent at least 15,000 requests (derived: 300 addresses times the 50 request minimum, assuming each address sent one burst of the stated size). Those are numbers a site owner can check against a log. The post does not print the 90 paths.

That is the first gap, and the post has more. It does not say how many organisations are in its study, which day the scanner reached 48 percent of them, which cloud provider the addresses belonged to, or whether anything was found or taken. It says the actor looked for passwords, API keys and cloud credentials. It does not say any were obtained, and it says nearly all of the actor's requests ended in a block or a failure at the organisations Cequence protects. Sites that Cequence does not protect are outside what it can see.

This briefing rests on the Cequence blog post "Attackers Are Using AI Agent Impersonation to Hunt for Credentials", dated 28 October 2026 and written by Cequence's Director of CQ Prime Threat Research and Data Science, which we read in full on Friday 30 October 2026, between about 15:37 and 15:45 GMT. SecurityWeek's roundup of 30 October 2026 carried a short item on it under the headline "Fake ChatGPT and Claude bots probe sites for leaked secrets"; its figures match the post, and it adds nothing to them. Cequence sells bot management, API security and agentic AI governance, and the post closes by recommending behaviour based bot management, so the vendor has a commercial interest in the finding. The impersonated names belong to OpenAI, Anthropic, Meta and Perplexity, among others; none of them is quoted in the post, and nothing in it says any of them was at fault.

What Cequence measured, figure by figure

The post reads as a summary of a study more than as a method. The word "study" appears ("At several organizations in the study", "the financial services organizations CQ Prime Research studied"), but the post gives no organisation count, no sampling window beyond the activity dates, and no request totals. The table separates what the post states from what a reader has to be careful not to add.

Two of those lines are easy to misread. The 48 percent is a share of customers that saw any AI bot traffic that day, not of all customers and not of all websites. And the 80 percent is the impersonator's share of the traffic that carried an AI bot label, which says more about how unreliable the label is than about how large the scanner is. Cequence draws that second conclusion itself: any AI bot metric that relies on self reported identity likely counts impostors as real agents.

How the impostor was recognised, and the check the post does not describe

The post lists what it calls the tells. Real AI bots behave predictably, it says, and this scanner broke almost every pattern. In its words, it cycled evenly through all 32 identities, which no legitimate bot does. The same 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 the post says points to a copied and pasted string. And it never identified itself or offered a contact address of its own, where legitimate scanning services publish who they are and where they scan from.

Those are behavioural and consistency checks on the claimed identity. The post does not say the addresses were compared with address ranges published by OpenAI, Anthropic, Meta or Perplexity, and it does not say reverse DNS was used. It does recommend published address ranges, signed requests and direct integrations as the way to verify an agent, so the method it advises is not the method it says it used to spot this actor. That matters for a reader who wants to repeat the finding: the post gives the tells, not a rule you can run.

On attribution to one actor, the post offers one sentence: shared addresses and technical fingerprints across targets tie the activity to one actor. Neither the addresses nor the fingerprints are printed. The same disguises, probe paths and request patterns repeat at every target, which is the behaviour Cequence says it uses. The claim of a single actor is Cequence's inference from data we cannot see.

Zoom

The routine, and why an address list goes stale

Cequence describes the scanner's routine in a few sentences. It first sends random nonsense paths to find websites that answer every request, which the post calls a common scanning technique. Then it ignores web pages and asks for files that commonly store secrets: .env configuration files, cloud credential files, private SSH keys and server environment data, from the list of roughly 90 file paths. It works through targets one at a time, around the clock, and moves to a new address after each short burst.

Zoom

The address figures explain the vendor's argument against blocklists. The actor used more than 300 cloud addresses in one day and nearly 400 in one week, and none of the late September addresses reappeared a month later. Third party threat feeds flagged many of them on the days they were used, the post says, but by then the scanner had usually moved on. The advice that follows is to expect IP blocklists to go stale within days against this kind of activity.

Cequence's own figure shows the pattern. It plots the cloud addresses seen impersonating AI bots on 21 October 2026 over the previous 30 days, one row per address. A teal dot marks a flag by a third party threat blocklist, and a red dot marks requests blocked by Cequence, larger for more requests. The figure's own footnote says addresses rotate constantly, so it shows one day's set and not the full campaign.

Zoom

Reading the figure by eye (approximate, not exact dates): most of the teal third party flags fall in a band in the middle of October, in the days leading up to and overlapping the largest red clusters of Cequence blocks. A handful of red dots sit in late September and early October. Two points follow, and both are our reading, not Cequence's. First, the 109 addresses in the figure are fewer than the more than 300 the post gives for its busiest day, so the figure cannot be that day's set; the post does not say which day had 300. Second, the text says none of the late September addresses reappeared a month later, while the figure's few early red dots suggest some of the 21 October addresses had been active earlier in the 30 days. That is not a contradiction on its face, because 21 October is under a month after late September, but the post does not reconcile the two, and the figure does not say whether those early dots belong to the same addresses as the late September set.

The friendly name: what an AI bot label is and is not

A user agent string is text the client chooses. Every control keyed on it, an allow rule for a named AI crawler, a rate limit that treats crawlers kindly, a dashboard that counts AI bot visits, inherits that weakness. Cequence's numbers put a size on it for the organisations it studied: at several, the impostor was more than 80 percent of what was labelled AI bot traffic. A report built on the label would have shown a busy AI audience that was one scanner looking for secrets.

The post also separates this scanner from the agents it says banks worry about. Those agents, it says, log in with a customer's own credentials through an ordinary browser and do not announce themselves, and they made up fewer than 1 in 4,000 requests at the financial services organisations studied. So the impersonated identities are the ones that want to be seen, such as crawlers and assistants with published names, and not the browser based agents behind the bank scenario that opens the post. Cequence also says attackers are probing which agents a business trusts and then impersonating those, but the post shows no data for that claim, and the news report it cites on bank account access is one we did not read.

A different case of borrowed AI names, in which genuine signed files were wrapped in fake ChatGPT and Claude desktop apps, is covered in our briefing on the Yoba malware. The mechanism there is a trojanised download; here it is a header. The shared lesson is that an AI brand on the outside tells you nothing about what is inside.

What the post states, and what it does not

One caution on wording. The post's title and opening describe attackers using AI agent impersonation to steal credentials. What it measured is requests for files, almost all blocked or failed. That is an attempt, recorded by the party that blocked it, and the word steal is Cequence's description of the aim, not a finding of any theft.

What to do, in the order worth doing

Technical details

Cequence's post prints none of the usual artifacts: no list of the 90 file paths, no user agent strings, no addresses, no hashes and no detection rule. It names four kinds of file (.env configuration files, cloud credential files, private SSH keys, server environment data) and nothing more specific. The blocks below are therefore derived by this site as defensive starting points. They are not Cequence's list, they are not the scanner's list, and they were not tested against any traffic.

Block one is a web server rule that refuses dotfile paths and common private key file names. It belongs in the server or virtual host configuration. A defender should check it does not break a legitimate path, and note it keeps the standard .well-known folder reachable.

# derived: refuse dotfiles (except .well-known) and common private key file names
<LocationMatch "^/(.*/)?\.(?!well-known/)">
    Require all denied
</LocationMatch>
<FilesMatch "^(id_(rsa|dsa|ecdsa|ed25519)|.*\.(pem|key))$">
    Require all denied
</FilesMatch>

# derived: answer 404 for dotfiles (except .well-known) and common private key file names
location ~ /\.(?!well-known/) { return 404; }
location ~* /(id_(rsa|dsa|ecdsa|ed25519)|[^/]+\.(pem|key))$ { return 404; }

Block two searches a combined format access log for successful responses on secret looking paths, then counts the user agents that asked. A defender runs it on a web server or on exported logs. A hit is a lead, not proof of exposure, because a site that answers every path with a success will match too.

# derived: any 2xx response on dotenv, cloud credential or ssh paths
grep -E '"(GET|HEAD) [^ ]*/\.(env|aws|ssh)[^ ]* HTTP/[0-9.]+" 2' access.log

# derived: which user agents asked for those paths at all, most frequent first
grep -E '/\.(env|aws|ssh)' access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head

Block three shows two ways to check a client that claims to be a named crawler. Both need data from the operator itself. Cequence names published address ranges, signed requests and direct integrations; it does not mention reverse DNS. The addresses below are from the documentation range reserved for examples, and the file of ranges must come from the operator's own published list. This site has not fetched any operator's list for this briefing.

# derived: reverse lookup, then forward lookup of the name returned; both must agree,
# and the name must sit under a domain the operator documents (only if it documents one)
host 203.0.113.10
host crawler-example.operator.example

# derived: is the client address inside the ranges the operator publishes?
import ipaddress
ranges = [ipaddress.ip_network(r) for r in open("operator-ranges.txt").read().split()]
client = ipaddress.ip_address("203.0.113.10")
print(any(client in r for r in ranges))

The question that exposes the gap

Look at last week's access log and find every client that called itself an AI crawler. Now ask what each one asked for. A real crawler wants pages; Cequence's scanner wanted .env files and private keys under a borrowed name. If the honest answer is that your allow rule, your rate limit and your AI traffic report were all keyed on the name, then the control was the label. Which of your systems would notice that a request claiming to be a ChatGPT or Claude crawler was asking for your credentials, and who would be told?

Key facts