METR 入侵事件凸顯 LLM API key 如同現金

The METR attacker spent three weeks inside a researcher's cloud instance and touched nothing sensitive. They burned roughly $600,000 in inference credits instead, and that should change how you handle your own keys more than any data breach this year.

Short version: a researcher ran agents on a personal, internet-facing EC2 instance holding a key to METR's general-access account. A vibe-coded agent app had a fail-open bug that silently disabled the Google auth in front of it. The attacker likely found it by scanning certificate transparency logs for LLM-flavored hostnames, then just asked the agent for its provider API key. The agent answered. Nobody noticed for three weeks, partly because METR's usage is enormous and spiky, partly because the credits were donated so there was no bill to trip over.

Stolen inference has no laundering step

Stealing data is a business with friction: you need a buyer and a way to prove the goods are real. Stolen compute converts to value immediately. Run your own workloads or resell access through a proxied endpoint. This pattern has a name, LLMjacking, and METR is the cleanest public case of it working at scale. The attacker monetized the most liquid thing on the box, and it wasn't data.

Spend alerts are the weakest control that matters

Every recap name-checks spend alerts. I think that's backwards. Alerts alone tell you how bad the damage was. Scoping limits what a stolen key can buy. Caps decide how much it can cost.

My rules:

• One key per workload, never per person or per org. When one leaks, you revoke one thing and know exactly what broke.
• Personal infrastructure gets personal keys, or no keys. Write that policy before the incident, not after.
• Agents should not hold provider keys at all. Broker them through an internal endpoint so a prompt-injected (or just helpful) agent has nothing to hand over.

Then every key gets a hard monthly cap, roughly 2x to 3x its historical peak, soft alerts at 50% and 80%, a page at 95%. If the provider can't cap that key class (METR's exact situation), put the key behind an egress proxy or LLM gateway you control and enforce caps there:

- 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

Detection has to be per key, not per org. Three weeks of abuse hid inside METR's org-wide volume. An experiment key burning at 4x its own baseline on a Sunday at 3 a.m. stands out even when the org total looks normal. Also alert on off-schedule spend: evals run on schedules, thieves don't.

Your agent dashboard is in certificate transparency logs

The moment you get a cert for agent-dashboard.example.com, the name sits on a public list that attackers grep for LLM and agent keywords. Assume it gets catalogued the day it goes up.

So test auth from outside, and test the error path, not just the happy path. METR's bug was fail-open. Run this from an unauthenticated context, on a schedule:

curl -s -o /dev/null -w "%{http_code}\n" https://agent-dashboard.example.com/

A 200 means auth just failed open. Test revoked tokens and an unreachable identity provider too. And watch CT logs for your own namespace. It's the same recon the attackers run, pointed inward.

What I'd do this week:

• Inventory every provider key with scope, owner, and monthly burn. If your team can't build that list in an afternoon, that's the finding.
• Cap every key, and keep a short-TTL break-glass key so a firing cap during a deadline never becomes the reason someone bypasses the control.
• Take provider keys out of agent processes entirely.
• Curl your own dashboards unauthenticated. Today.

My claim to argue with: spend alerts as a primary control just make teams feel covered while scoping and caps do the real work. Agree?

Longer writeup with the full timeline and the PromQL alert rules: https://axeploit.com/blog/one-key-three-weeks-600000-attackers-are-cashing-out-ai-credits-not-data