One Key, Three Weeks, $600,000: Attackers Are Cashing Out AI Credits, Not Data

Something changed in the METR breach, and most of the coverage walked right past it. The attacker sat on a researcher's cloud instance for three weeks and touched nothing sensitive. They burned roughly $600,000 in inference credits instead, and that fact should change how you handle your own keys more than any data breach this year.

What happened, in the parts that matter for your keys

METR (Model Evaluation and Threat Research, a nonprofit that evaluates frontier AI models on long-horizon, agentic tasks) disclosed on August 31, 2026 that an attacker stole one of its API keys back in March and spent three weeks consuming about $600,000 worth of credits on publicly available models. Read METR's own disclosure; it is unusually candid. The news recaps covered the timeline thoroughly, so here are only the details that should drive your controls:

A researcher with no access to sensitive systems ran agents on a personal EC2 instance, deliberately internet-facing behind Google authentication. The instance held a key for METR's general-access account.
The researcher's vibe-coded agent app had a fail-open bug that silently disabled that Google auth. The agent orchestration dashboard sat exposed for several days.
METR suspects the attacker found it by scanning certificate transparency logs for recently registered sites with LLM and agent keywords, hunting vibe-coded deployments with harvestable keys.
The attacker then prompted the agent to reveal its model provider API key. They asked, the agent answered. An SSH key went in for persistence.
Nobody noticed for three weeks. METR runs enormous evaluations constantly, and staff were, as The Register reported, "very acclimated to getting lots of weird rate limit and API errors." The credits had been donated by the model provider, so there was no bill and no natural ceiling, and at the time there was no way to put a spending limit on that class of key. The internal usage dashboard did not even show rate-limited requests to all users.

Then there was a second incident. In May 2026, a likely financially motivated actor ran a sustained campaign against METR's public infrastructure: agents automating vulnerability discovery, credential stuffing, OAuth token grant attempts, scanning newly deployed services, phishing staff. Around the same period, an outside researcher found that a read-only SQL query feature in METR's public transcript viewer could, via a bug, have reached unpublished evaluation data; METR paid a bounty, took it offline, and found no evidence attackers exploited it.

METR's response was by the book: revoked access, imaged the instance, rotated every credential, wiped the researcher's laptop, alerted the partner AI company. Afterwards it tightened policy on company credentials living on non-company infrastructure, improved monitoring, added spend alerts where possible, and hired a security lead. Nothing from its two most sensitive data categories was accessed in either incident. Good. But the lesson lives in that first incident: the cheapest thing for the attacker to monetize was never the data.

AI credits are a bearer asset

Stealing data is a business with friction. You need a buyer, a channel, a way to prove the goods are real. Stolen inference has none of that. Compute converts to value immediately: run your own workloads, resell access through a proxied endpoint, power whatever service you like. No laundering step, no negotiation.

This is the monetization pattern now known as LLMjacking, and METR's March incident is the cleanest public example of it working at scale. The May campaign shows the same logic from another angle: the goal was illicit access to frontier models, not METR's evaluation results.

I will go further than the news coverage did. Spend alerts are the control every recap name-checks, and they are the weakest of the controls that matter. Scoping limits what a stolen key can buy, and caps decide how much it can cost. Alerts on their own just tell you how bad the damage was.

Scope keys so one leak pays for one workload

METR's own data classification is a decent template: Published, Generic model access, Sensitive model access, Highly sensitive information. The stolen key only reached the generic tier, which is exactly why this incident was expensive instead of catastrophic. That separation worked.

The rules I use:

One key per workload, never per person or per org. The batch eval job gets its own key. The chatbot gets its own key. The researcher's weekend agent experiment gets its own key with a small cap. When one leaks, you revoke one thing and you know exactly what broke.
Personal infrastructure gets personal keys, or no keys. METR's post-incident policy update covers precisely this: company credentials on non-company devices and infrastructure. Write that policy before the incident, not after.
Agents should not hold provider keys at all. The METR attacker got the key by asking the agent for it. Put a broker between the agent and the provider: the agent calls your internal endpoint, your endpoint holds the key and enforces scope. A prompt-injected or simply helpful agent then has nothing to hand over. The sensitive-information and excessive-agency categories in the OWASP LLM Top 10 checklist map directly onto this.

Concrete first step: produce an inventory of every provider key your organization holds, with scope, owner, and monthly burn per key. Most teams cannot build that list in an afternoon. That is the finding.

Caps and alerts: the ceiling METR did not have

The detail I keep returning to: there was no way to cap spend on the stolen key, and because the credits were donated there was no billing signal at all. Free credits are the worst case for detection. No invoice, no budget owner asking questions, no card declining.

Decision rules:

Every key gets a hard monthly cap, sized at roughly 2x to 3x its historical peak month, reviewed quarterly.
Soft alerts at 50% and 80% of cap to the owning team, a page at 95%.
A break-glass key with a short TTL and loud alerting, so a firing cap during a real deadline never becomes the reason someone bypasses the control.
Where the provider cannot cap that key class (METR's exact situation), put the provider key behind an egress proxy or LLM gateway you control and enforce caps there. The provider key never touches developer machines or agent processes; your gateway mints the per-workload keys.

yaml

# per-key policy, enforced at your gateway if the provider cannot
- key: evals-batch-prod
  scope: ["chat:completions", "batch"]
  monthly_cap_usd: 12000
  alert_at: [0.5, 0.8]
  page_at: 0.95
- key: researcher-experiment-mk
  scope: ["chat:completions"]
  monthly_cap_usd: 200

Anomaly detection must be per key, not per organization. Org-wide token volume at a place like METR is huge and spiky, which is exactly why three weeks of abuse hid inside it. A per-key baseline fixes that: an experiment key burning at 4x its own two-week baseline at 3 a.m. on a Sunday stands out even when the org total looks normal.

promql

# alert when a key's hourly burn exceeds 4x its own 14-day baseline
  sum by (key_id) (increase(llm_tokens_total[1h]))
/ on (key_id)
  avg_over_time(sum by (key_id) (increase(llm_tokens_total[1h]))[14d:1h])
> 4

Also alert on off-schedule spend. Evaluations run on schedules; thieves do not. If a key only ever burns during batch windows, any burn outside them is a page.

Your agent dashboards are in certificate transparency logs

This is the tradecraft detail that should change behavior well beyond METR. The suspected discovery method was scanning CT logs for recently registered sites with high-signal LLM and agent keywords, looking for vibe-coded dashboards. Anyone can watch certificate issuance. The moment your team spins up agent-dashboard.example.com and gets a cert, the name sits on a public list that attackers grep.

Two controls follow.

First, fail-closed auth, tested continuously. The METR bug was fail-open: an error path silently disabled Google auth. Auth middleware will fail; the question is which way. Test from outside, on a schedule:

bash

# run from an unauthenticated context: no SSO session, no cookies
curl -s -o /dev/null -w "%{http_code}\n" https://agent-dashboard.example.com/
# 200 means auth just failed open. 401, 403, or a redirect to login is expected.

Test the error path too, not just the happy path: revoked tokens, mangled tokens, identity provider unreachable. A dashboard that returns 200 to the world is worse than no dashboard at all, because it breeds false confidence. The same audit posture applies to any exposed AI service; we published a lockdown playbook in Check the Socket, Not the Installer.

Second, watch CT logs yourself. Alert on new certs for your domains and for agent or LLM-flavored hostnames in your namespace, then scan whatever stands behind them for open dashboards and key material. Public CT search tools make this trivial, and it is the same recon the attackers run, just pointed inward. The broader pattern, a demo that works fine on a laptop becoming a liability the day it gets a public cert and a real key, is exactly the production gap we mapped in Your Agent Demo Is Lying to You.

And the cultural fix, stated plainly: vibe coding internal tools is fine. Shipping them with provider keys inside, auth that fails open, and a public certificate is not. Speed is the point of vibe coding; review is the tax on that speed.

"Our usage is too spiky for alerts" and other objections

Two pushbacks come up every time I propose this.

"We run huge evals; anomaly detection would page us constantly." METR is the spikiest-usage organization imaginable, and the lesson still holds, because the fix is per-key baselines and schedule-aware alerting, not static thresholds on org totals. Your eval key's burn is spiky in a pattern. The attacker's burn is steady, off-schedule, and on the wrong key. Those signals are distinguishable.

"Caps will take down production when they fire." A cap that pages a human at 95% and has a break-glass path does not take anything down; it forces a decision. The alternative is what METR had, which was no decision point at all for three weeks. Note that METR's own remediation landed in the same place: spend alerts where possible, better monitoring, tighter policy on credentials off company infrastructure.

One more uncomfortable point. METR holds a SOC 2 Type I certification and lists sound principles: centralized identity, network isolation, minimal permission scoping, cross-platform monitoring. A personal EC2 instance with a company key still sat outside all of it. Audits check the systems in scope, and side experiments are never in scope, a gap we wrote about in Your AI Agents Are One Audit Question Away From a Finding. The distance between the policy document and the researcher's keyboard is where the $600,000 went.

Put usage caps in the AI budget, next to the headcount

Last piece, and it is the one almost nobody does: make the cap a budget artifact, not only a security control.

Finance already runs on budgets. Map each AI cost center (product feature, research project, eval pipeline) to its own keys, and set each key's cap from the budget line. Now the cap has an owner who cares for financial reasons, which means it gets reviewed without security nagging. Anomaly alerts route to the team paying the bill, and people respond very fast to alerts denominated in their own budget.

For donated or granted credits, use commercial value as the budget number. METR lost nothing out of pocket and still saw $600,000 of real value consumed; if your credits were free, the attacker spends your provider's goodwill, and the awkward conversation with that provider is still yours. METR, to its credit, alerted the partner AI company and briefed the AI companies it works with before going public.

The budget process also keeps key inventory alive. Keys die when projects die, as long as the budget line dies with them. Orphaned keys with live spend are the quiet version of this same incident.

Leaked keys and forgotten cloud assets are an attack-surface problem. Axeploit is the scanner we use for that class of finding. If the inventory exercise above sounded painful, it still beats having someone else do the inventory for you.

If you want this checked automatically

If you want the auth and object-level checks in this article run against a live app, start with Axeploit's API security checker.

Key takeaways

AI API keys are bearer assets now. Attackers monetize inference directly instead of exfiltrating data, so store, scope, and monitor keys accordingly.
One key per workload, and no provider keys inside agent processes. The METR attacker got the key by asking the agent for it.
Every key needs a hard cap tied to a budget line, soft alerts at 50% and 80%, and per-key anomaly detection. Org-wide token totals hide exactly this kind of theft.
Assume every agent dashboard is discoverable through certificate transparency logs within hours of issuance. Test from outside, on a schedule, that auth fails closed.
Free or donated credits are the worst case for detection because no bill ever arrives. Cap them at commercial value anyway.