Fake AI Bots Probe Enterprise Servers for Passwords, API Keys and Cloud Credentials

The key weakness in this campaign wasn’t a sophisticated exploit. It was the assumption that a bot’s declared identity means anything. Cequence researchers tracked one actor posing as roughly 32 AI agents while probing enterprise servers for files that can expose passwords, API keys and cloud credentials. That distinction matters: the activity didn’t depend on breaking into a system first. It depended on finding sensitive material that might already be reachable from the web.

The scanner claimed identities associated with OpenAI, Anthropic, Meta and Perplexity, sometimes switching between them within seconds. It targeted organizations in financial services, retail, telecommunications, energy and software, with activity observed from at least late September through late October 2026. A familiar name in a request may make traffic look routine, but it doesn’t establish who sent it or why. In this case, the rotation itself undercuts any assumption that a user-agent label is a reliable credential.

A scanner tuned for exposed secrets

Rather than browse public pages, the tool requested about 90 paths commonly associated with secrets, including .env files, cloud credential files, private SSH keys and server environment data. Those files can contain information that helps someone access systems or services, though their presence on a server doesn’t by itself show that they were exposed or retrieved. The pattern of requests gave defenders a more useful clue than the bot’s claimed identity: the scanner was looking for material that ordinary crawlers typically have no reason to request.

Cequence director of threat research Will Glazier said the scanner sent bursts of 50 to 190 requests in roughly eight seconds before moving to another set of paths. That pace can make a scan conspicuous to systems that track request volume and sequence, while still giving it opportunities to test many locations quickly. It also means a defense focused only on one request at a time could miss the broader pattern. The signal is in the combination of targets, timing and repetition.

The requests came from infrastructure at an unnamed major cloud provider. The actor also used more than 300 cloud addresses in a single day, limiting the value of static IP blocklists on their own. Blocking one address may stop that source temporarily, but it doesn’t establish that the next address belongs to a different actor or poses a different risk. Cequence said nearly all the requests were blocked or failed; it reported no breach. That’s a meaningful distinction: the report describes probing activity, not evidence that the scanner obtained credentials.

The scale was notable: on one day in October, the activity reached 48% of Cequence-protected organizations that had seen any AI bot traffic. That figure describes the company’s monitored organizations, not the wider market. It suggests this actor was prominent within that particular group of observed traffic, but it can’t establish how common the behavior is across all organizations or AI bots. The numbers here are striking, but their boundaries matter.

A name in a header proves nothing

Collin Hogue-Spears, senior director of solution management at Black Duck, said the scanner was testing whether websites accepted an AI bot’s self-declared name as proof of identity. “The user-agent header is where a visitor names itself, and setting it costs nothing,” he said. In practice, a server reading that label learns what the requester claims to be; the label alone doesn’t verify the claim. This is the same basic problem security teams face whenever a system treats a supplied identifier as authentication.

That makes behavior a more useful signal than a bot’s label. Cequence recommends checking claimed crawlers against published address ranges, signed requests or direct integrations, and flagging bots that seek credential files. Each approach gives a defender a way to compare a claim with other evidence, although the right check depends on how the organization’s services are designed. Here’s the thing: a recognizable name can help sort traffic, but it shouldn’t be the final decision point.

Security teams should also keep secrets outside web-accessible directories and assess automated traffic by what it requests and how it behaves. This is more significant than it looks: the same exposure can matter regardless of whether a request comes from a self-described AI agent, a crawler or another automated client. (And this is the part most people overlook.) If a sensitive file isn’t reachable from the web, a scanner’s ability to guess its path has less to work with.

DataVisor CEO Patrick Harr described fraud as increasingly polymorphic, warning that attackers can vary their methods faster than static defenses are updated. His view: real-time detection needs to adapt at a similar pace. That argument applies here in a specific way: shifting names and addresses can weaken rules built around a single label or source. A changing pattern. But adaptation still depends on defenders collecting enough context to distinguish suspicious behavior from legitimate automated traffic.

Extend identity controls to agents and service accounts

Keeper Security CISO Shane Barney said zero-trust controls and least-privilege policies should cover AI agents, API keys and service accounts. He also recommended replacing long-lived local credentials with centrally managed secrets. These controls address different parts of the problem: access limits can reduce what an identity is able to reach, while central management gives teams a clearer place to track and change credentials. Neither makes a self-declared user-agent trustworthy.

“When an identity starts looking for sensitive files it shouldn’t need, real-time threat detection must flag and terminate that machine session instantly,” Barney said. For security teams, the practical test is simple: verify the identity, then judge the traffic by its actions. If you’re working in this space, that means asking whether an automated client has a verified reason to access a resource, and whether its requests match that purpose. The label is a starting clue, not a verdict.

What the campaign signals for defenders

The episode points to a basic operational challenge: automated traffic can present a plausible identity while acting in ways that don’t fit the claimed role. Organizations that allow AI agents, crawlers and service accounts to access their systems need controls that connect identity to permitted activity. That includes watching for requests to sensitive paths, considering request patterns across changing addresses and limiting the consequences if a credential or file is exposed. The reported scan failed in nearly all cases, but that doesn’t make the underlying exposure question academic.

There’s a limit to what the available account can establish. Cequence reported no breach, and its monitoring figure describes its own protected organizations; the source doesn’t show whether any credentials were found elsewhere or how the actor would have used them. Still, the defensive lesson is concrete: don’t grant trust because a header names a familiar AI company. Verify the requester where possible, keep secrets out of public paths, and treat the traffic’s purpose as evidence.