[FORECAST] Stolen AI Tokens Are Becoming the New Cloud Skeleton Key

Core question: By 2027-07-01, will at least two public enterprise-impact incidents report stolen AI-service session tokens or API keys as a material enabler of cloud, code, SaaS, data, or compute abuse?

The call: We assess a 94% probability that, by July 1, 2027, at least two public enterprise-impact incidents will report stolen AI-service tokens or API keys as material enablers of abuse. In practical terms, the forecast is likely already resolved Yes—but remains under audit because one qualifying incident is anonymized.

The defender tension is immediate. Organizations increasingly depend on AI credentials that can survive password resets, bypass a fresh MFA challenge, consume expensive inference, and feed proxy infrastructure. Yet those credentials often sit in developer environments governed more like convenience tokens than production secrets.

The practical response is not exotic: inventory the authority, reduce its replay value, detect use at the credential level, and make AI-token revocation part of endpoint incident response.

TL;DR

• The 94% judgment is resolution confidence, not a forecast of attack frequency. The two-incident threshold appears to have been met already.
• METR supplies the first incident. Attackers stole an AI API key from an exposed agent-orchestration dashboard and consumed roughly $600,000 in model credits over about three weeks.[1]
• Unit 42 probably supplies the second. Its incident-response reporting describes attackers stealing exposed organizational AI credentials, placing them into proxy “transfer stations,” and causing nearly $1 million in charges.[2]
• The remaining caveat is source qualification. Unit 42 does not name the victim, provider, precise credential type, or unique incident date. The report strongly supports a qualifying incident, but a strict external resolver could reject anonymous reporting.
• Exposure alone does not qualify. The attacker must acquire or use the AI credential, and that credential must materially enable organizational financial or operational harm.
• MFA is not the complete control. Unexpired session material and bearer-style API keys can remain replayable without another normal sign-in event.[3]
• The principal decision: govern reusable AI credentials like privileged production secrets and connect their lifecycle to developer-endpoint, identity, cloud, and billing response.
• One clean win: add AI API-key rotation and AI-session revocation to the standard playbook for infostealer activity on a developer endpoint.

The “skeleton key” is not a claim that every AI token opens every cloud service. It describes the operational role these credentials can assume: portable authority that converts quickly into paid compute, proxy access, account changes, or access to connected enterprise workflows.

The forecast appears resolved, but the evidence still needs an audit trail

The forecast question was deliberately narrow:

By July 1, 2027, will at least two public enterprise-impact incidents report that stolen AI-service session tokens or API keys materially enabled cloud, code, SaaS, data, or compute abuse?

A qualifying incident requires more than a secret appearing in a repository or infostealer log. Public reporting must establish four things:

1. An attacker acquired or used an AI-service session token, API key, or equivalent credential without authorization.
2. The stolen credential materially enabled the abuse rather than appearing incidentally.
3. An organization suffered, or credibly faced, meaningful financial or operational consequences.
4. The incident was distinct from any other incident counted toward the threshold.

Attacker-created accounts do not count. Generic cloud, source-control, or SaaS credentials do not count merely because AI was involved later. Exposure without reported acquisition or use does not count.

Under those fixed rules, the evidence supports two incidents.

METR establishes the first incident with high confidence

METR reported that attackers found a publicly exposed agent-orchestration dashboard in March 2026. The attackers prompted an agent to disclose an API key used for inference on public models, added an SSH key for persistence, and used the stolen credential for approximately three weeks.[1]

METR estimated that the consumed API credits would have been worth roughly $600,000. That gives the incident a named organizational victim, explicit credential theft, observed use, material compute consumption, and a direct causal link between the stolen key and the impact.

We assess a 99% probability that this incident qualifies.

Unit 42 probably establishes the second—with an important caveat

Unit 42 reported responding to a growing number of organizational “token-jacking” cases. According to the report, attackers stole inadvertently exposed credentials, integrated them into AI proxy infrastructure within minutes, and generated nearly $1 million in charges before discovery and containment.[2]

The mechanism is material. The stolen credentials were not decorative evidence in a larger intrusion; they were the input to a resale and consumption system.

The report also predates METR’s public disclosure, and its transfer-station activity and near-$1 million charge profile differ from METR’s account. Those facts support treating it as separate evidence rather than a retelling of the named METR incident.

But the affected organization is anonymous. Unit 42 also does not publicly identify the AI provider, precise key type, or unique incident date. We therefore assess a 95% probability that the report establishes at least one distinct qualifying incident—not 99%.

That caveat must remain attached to the judgment. The uncertainty is not whether Unit 42 reported material theft and use of organizational AI credentials. It is whether an external resolver will accept an authoritative but anonymized incident-response disclosure as a public incident report.

Combining the two qualification judgments produces the current 94% call. We did not sharpen it further merely because the sources are independent; the anonymous Unit 42 case does not support more precision than it contains.

Evidence boundary

Observed: METR directly disclosed theft and unauthorized use of its AI API key, persistent access to the exposed system, and approximately $600,000 in consumed model credits.[1] Unit 42 reported organizational cases involving stolen AI credentials, rapid integration into proxy infrastructure, and nearly $1 million in charges.[2] Okta separately found AI-session artifacts and 24 still-valid AI-related API keys in an infostealer dataset representing 5,871 infected machines.[3]

Assessed: The two-incident threshold is probably already satisfied under the forecast’s explicit anonymous-victim rule. We assess this at 94%, with medium confidence in the complete input set.

Unknown: Unit 42 has not publicly supplied the victim identity, provider-specific credential attribution, or incident-level timeline needed to remove the remaining resolution ambiguity. Public reporting also does not provide an auditable historical denominator for this narrowly defined event class.

Not counted as an incident: Okta’s infostealer dataset demonstrates credential availability and replay risk, but it does not itself establish material enterprise impact from the discovered tokens.[3] It is a leading indicator, not a resolution event.

What would change our mind: A finding that Unit 42’s reported case used something other than a stolen AI-service credential, did not causally produce the reported charges, or overlapped with METR would lower the judgment. Conversely, corroboration from a provider, customer, regulator, insurer, or court would move confidence toward 99%.

The meeting-worthy question

Team question: If an infostealer hit a developer laptop this morning, who could identify every reachable AI credential, revoke it, and prove by the end of the day that replay had stopped?

If the answer requires several teams to discover one another during the incident, that is the decision to fix.

The attacker still needs usable authority, time, and enough unmonitored consumption to make the theft pay. Defenders do not need perfect visibility to take those conditions away. They need credentials with owners, constrained replay, joined telemetry, and a revocation path tested before the bill becomes the incident report...

Public reporting establishes the abuse. Below the tear line is the operational decision model: how to govern AI credentials by replay value and blast radius, connect infostealer response to revocation, and build credential-level detections for inference, billing, proxy, and control-plane abuse.

Govern tokens by authority, replay value, and blast radius

A single label such as “AI credential” hides materially different risks. A browser session artifact, a static model-provider key, an internal AI-gateway credential, and a cloud service identity may all authorize different actions and expire on different schedules.