Exposed Agent Keys Can Become a Route into Infrastructure: What Leaked AI and MCP Credentials Actually Expose

By Adrian Cheek, Senior Cybercrime Researcher

One record in the corpus carries the argument before we even start counting. It’s a project configuration file for an AI coding assistant that wires several named tool servers behind a single agent. The file does not hold the secrets, but it points to them: an environment block, a row of variable names ending in _API_KEY and _TOKEN, each one a door the agent is built to open. The values live in the environment beside the file, the same environment a commodity infostealer copies in full the moment it reaches the host.

That gap between the configuration and the secret is the finding, and a collection of this size lets us measure rather than assert it. The industry has hunted leaked agent credentials as if they behaved like passwords in a dump, which they don’t. They actually behave like wiring diagrams that tell an attacker which secrets to take and what each one unlocks.

Key Findings on AI and MCP Exposure

• Pattern matching across 12,446 unique records, after de-duplication by credential value and removal of placeholder and template keys, leaves 438 distinct credentials (218 once a single concentrated harvesting operation is set aside). Of these, 315 are LLM-provider keys and 122 are downstream secrets.
• Infostealer exfiltration is the single largest source of leaked LLM keys, accounting for 259 of the 437 distinct credentials against 107 recovered from committed code and container layers.
• Freshness is high. Of 315 dated LLM keys, 270 trace to a source log 30 days old or less and 307 to one 90 days or less.
• A large Groq cluster is real but concentrated: 220 of 260 Groq keys come from two automated credential-checker accounts. Set those aside and Groq still leads the victim-leak view, at 40 keys against 25 OpenAI project-scoped keys, but the margin narrows from roughly ten to one to three to two.
• The downstream tier is diverse and high-impact: database connection strings, cloud access keys, source-control tokens and live payment keys all appear.
• Across 2,327 MCP-config records and roughly 1,209 credential-bearing infostealer rows, genuine multi-secret bundles are vanishingly rare. The blast radius is assembled, not pre-packaged.

What is Already Known, and What We Add

We have counted AI credentials in stealer logs before. The 2023 stealer log and corporate access spotlight, drawn from 19.6 million logs, found that roughly 1% carried access to leading AI provider credentials, on the order of 200,000 logs. That work established the scale of the problem at the account level. It predates the shift that motivates this assessment: the move from a model key as a billing credential to a model key as the entry point of an autonomous agent wired to other systems.

Infostealers collecting AI tooling configuration is also documented. The Djinn Stealer family and the February npm supply-chain campaign both targeted Model Context Protocol (MCP) configuration paths by name. The structural weakness of long-lived static keys in MCP is set out in the OWASP MCP Top 10.

What none of that prior work answered is the question this corpus can: of the keys in circulation now, what is the provider mix, how fresh is the supply, and what does a leaked agent configuration actually expose. That is the gap this assessment fills, and against a 2025 stealer log volume that surfaced more than 50 million logs on underground channels, the supply this measures is not slowing.

Scope discipline. Drawn from a 13 file Flare feed-search export, the assessment covers 12,446 unique records after cross-file de-duplication. Figures are reported as a floor: the true circulating count is higher. No credential value is reproduced, tested, used, or validated. Where validity is discussed it is inferred from source-log recency.

The LLM-Key Population

The spine of the census is the set of provider API keys that grant billable model access, the credential an attacker monetizes directly by reselling access or running inference on someone else’s account.

Two views are reported below. The harvester-inclusive view counts every distinct key. The victim-leak view removes a single concentrated harvesting operation, described below, so the provider mix reflects independent leaks rather than one actor’s collection.

Table 1. Distinct LLM-provider keys by format. Floor figures, de-duplicated, placeholders removed.

The Groq cluster warrants qualification. Groq leads the harvester-inclusive count, but 220 of its 260 keys originate from two automated credential-checker accounts that repost validated keys in bulk. That is a harvesting operation, not 260 independent victim infections. Reported without this caveat it would distort the provider picture. In the victim-leak view Groq falls to 40 against 25 OpenAI project-scoped keys, so it remains first while the margin narrows from roughly ten to one to three to two. One likely contributor is that free-tier keys carry no billing consequence for the holder and tend to be rotated less often than keys tied to a paid account, though this corpus measures circulation rather than issuance and cannot confirm that. Among the OpenAI formats, the scoped key meant to limit blast radius is leaking as readily as the legacy format it replaced, at 25 project-scoped keys against 9 legacy.

The MCP Config as a Wiring Diagram

A note on terms first. Blast radius, in the identity-exposure sense, describes how far one compromised identity reaches across its connected services. That is an attribute of the victim and their account graph. The question here is narrower and different: whether a single leaked artifact, one MCP configuration file, contains that reach pre-packaged inside it. The two are not the same object, and the distinction is the point of this section.

The premise this assessment set out to measure was that one leaked MCP configuration carries several downstream secrets at once, turning a single leak into many. Across the full dataset, the evidence does not support that premise in the form posed, and the reason is more useful than the premise would have been.

The corpus holds 2,327 records containing an MCP server configuration. Of these, 96 carry any live extractable secret, and the large majority of those are a single database connection string sitting inside a container image layer rather than an agent wiring multiple services together. Genuine multi-secret agent bundles are the rare exception, not the rule. On the infostealer side the same pattern holds: of roughly 1,209 exfiltration records carrying credentials, only 2 hold two or more distinct secret types in one record.

This is not reassurance. The configuration names every service the agent reaches and the exact variable each secret occupies. An infostealer that takes the host environment, the default behavior of every commodity stealer, collects those values in the same pass. Config and environment sit side-by-side on the victim machine. Read together they reconstruct the full picture: which servers, which secrets, what each unlocks.

The blast radius is real. It’s assembled from two artifacts the same infection yields, not pre-bundled into one file an attacker can grep for. That distinction matters for defenders, because it means the config is worth protecting even when its values are stripped out.

That finding has an operational use beyond defense. The presence of an MCP configuration in a log is itself a risk signal: it marks a host where an agent identity was exposed, not just a browser password, and it warrants higher triage priority than a log of consumer credentials. The provider-format breakdown and the wiring-diagram finding define the signals such a prioritisation would consume. Flare’s StealerLens, which reads a log into a documented infection hypothesis, is moving toward risk labeling that could consume exactly this signal.

Recency and Likely Validity

Validity is not tested here. Recency is, and under the discipline applied to the FortiBleed analysis, it is a defensible proxy. Commodity stealer logs reach collection within roughly 48 hours of infection, so a key whose source log is recent was live on a real host days ago and is likely still live until rotated.

Table 2. LLM keys by age of source log. 315 of 315 keys carried a usable date. Recency, not tested validity.

The freshness here is the operational point. The large majority of dated keys trace to the last thirty days, so the leaked set is not a stale archive. It is a live, replenishing supply, and the recent subset is what a defender should hunt first.

Downstream Secrets and Source Spread

The downstream tier is where an exposed agent key stops being an inference-billing problem and becomes a route into infrastructure. The data shows real diversity rather than a single dominant secret type.

Table 3. Downstream / non-LLM secrets, de-duplicated.

Database connection strings dominate, followed by cloud access keys and source-control tokens, with a small number of live payment keys present. Each is a credential that, recovered alongside an agent configuration, extends reach from the model account into data, cloud, and code.

Table 4. Distinct credentials by where they surfaced.

Infostealer exfiltration is the largest single channel, which is the operationally significant reading: these are fresh credentials taken from live hosts, not stale keys recovered from old code. Committed code and forum redistribution follow.

Key Judgments

High Confidence

• LLM-provider and MCP-related credentials circulate in leaked-credential sources at measurable scale. A floor of 438 distinct credentials across 12,446 records establishes this; the true count is higher.
• MCP configuration files expose the full downstream wiring of an agent, naming each service and the variable holding its secret, even when they externalise the values.
• The leaked supply is fresh. The majority of dated LLM keys trace to source logs under thirty days old, indicating active replenishment rather than a static archive.

Moderate Confidence

• A meaningful share of leaked LLM keys are still live. Inferred from source-log recency, not from testing.

Not Supported

• The premise that a single MCP config commonly bundles several live downstream secrets. At full scale the configs externalize secrets and multi-secret records are rare. The multiplier exists across co-resident artifacts, not within one file.

Recommendations for Security Teams

• Rotate provider keys on a fixed cadence and on any signal of host compromise. Scoped key formats leak as readily as legacy ones, so scoping does not replace rotation.
• Treat an MCP configuration as sensitive in its own right. It is a directory of your agent’s reachable services and the secrets behind them, useful to an attacker even with values stripped.
• Hunt the recent subset first. Credentials tied to a source log under 30 days old are the most likely to be live.
• Assume any secret resident in a host environment alongside a leaked config is compromised together with it. Commodity stealers take the environment by default.
• Discount bulk credential-checker feeds when sizing exposure. Harvester-bot reposting inflates raw counts and skews provider attribution if taken at face value.

On What We are Not Publishing

A census like this is useful to defenders and useful to the other side, and the line between the two runs through the detail. A provider-format breakdown paired with a recency grade is, read the wrong way, a shopping list: it points at which key formats are worth harvesting and which are likely still live. So this assessment carries counts, prefixes and hashes, never values, and it reports recency rather than testing validity. The intent is to size the problem without handing anyone an accelerant. That is the same reasoning Flare applies to gating its own log-analysis tooling, and it applies as much to a measurement as to a tool.

What AI and MCP Credentials in Circulation Means

What matters most here is the gap between a configuration file and the secret it points to, and how easily one commodity infostealer closes that gap in a single pass. A leaked MCP config doesn’t need to bundle five secrets to be dangerous, but just needs to sit next to an environment block that a stealer was always going to grab anyway, and it turns that generic grab into a targeted one: here’s the server, here’s the variable, here’s what it unlocks.

That’s the shift this assessment set out to measure. LLM keys stopped being just billing credentials the moment they became the entry point for autonomous agents wired into databases, cloud accounts, and source control. The 315 provider keys and 122 downstream secrets counted here are a floor, not a ceiling, and 270 of those keys trace to a source log under 30 days old. This is a live pipeline that refills itself faster than most teams rotate their keys.

None of this requires a sophisticated attacker. It requires an infostealer that already does its job well, a config file that was never designed to be secret-bearing on its own, and a defender who treats the two as unrelated artifacts instead of two halves of the same exposure. Rotation, config hygiene, and prioritizing hosts where agent identities (not just browser passwords) were exposed close most of this gap on their own. The keys are already circulating, so defenders must start treating the wiring diagram with the same urgency as the secrets it points to.

Methodology

Passive, no-touch. Patterns matched against a thirteen-file Flare feed-search export de-duplicated to 12,446 records on event identifier; specific key prefixes matched ahead of the generic OpenAI residual to prevent double-counting; results de-duplicated by exact credential value and stripped of placeholder, template and repeated-character keys. A concentrated harvester-bot Groq cluster is reported separately rather than blended into the provider mix. No credential value is reproduced in this assessment or its workbook. We observe credentials in circulation. We do not test, use, or validate them.