$600,000 of Inference, Three Weeks, Nobody Noticed

METR — the org that independently investigated OpenAI's IM1 Hugging Face incident — disclosed this week that an attacker stole one of its API keys, added SSH persistence, and burned six figures in model credits before the model provider surfaced the abuse

On Aug 31, METR — the frontier-model evaluation nonprofit that produced the 91-page independent alignment investigation of OpenAI's July Hugging Face incident — published a security update disclosing two prior compromises of its own infrastructure. The bigger of the two, in March 2026, was covered on Sept 1 by The Register, Dark Reading, Infosecurity Magazine, and The Hacker News. An attacker reached a personal EC2 instance a METR researcher had stood up, pulled the API key it held, added an SSH key for persistence, and then spent about three weeks running inference on METR's dime. The bill was roughly $600,000. The abuse was surfaced by the model provider, not by METR.

The full chain, as METR describes it in its own post, is worth reading step by step. Every hop is ordinary. The compromise is in the joins.

The chain

• A METR researcher stood up a personal EC2 instance to run agents. It held an API key belonging to METR's general-access model account. The instance was supposed to be gated behind Google authentication.
• The authentication code was, per METR's own phrasing, vibe-coded, and it had a fail-open flaw that silently disabled the auth check. The instance was internet-exposed for several days.
• METR's own hypothesis is that the attacker found it by mining certificate transparency logs for newly registered domains containing AI- and agent-related terms.
• Once inside, the attacker prompted the app's agent to reveal the model provider API key, then added an SSH key for durable access.
• With the key in hand, the attacker ran inference on public models for about three weeks. Total spend: ~$600,000.
• METR did not detect the abuse. The model provider did.

METR is direct about why:

"The illicit usage was hard to distinguish from legitimate evaluation activity, since our researchers routinely generate high volumes of model traffic, and we had no way to cap spending on free-credit keys."

What this belongs next to

Two days earlier, Anthropic disclosed that commodity infostealer malware — Vidar, LummaC2, StealC, RedLine, Acreed on Windows, AMOS on Mac — had been retooled to include Claude session cookies in its haul, and a downstream actor was reusing those sessions to burn paid usage on hijacked accounts. Anthropic's own user-facing tell was written in the same shape: "if your usage limits looked like they refilled and then drained while you weren't using Claude, this was likely the cause."

Two independent incidents — one at a frontier lab, one at a frontier-model evaluator — disclosed inside 48 hours of each other, both saying variants of the same sentence. The terminal action of the compromise is inference consumption, and the account owner cannot tell it from real work at the runtime boundary.

Palo Alto Networks Unit 42 has been tracking the underlying market for a while: premium pricing on scarce AI compute makes stolen inference an unusually clean monetization path — no fencing step, no laundering step, no victim-notification lag before the money is realized. The attacker's payoff is denominated in the same asset the victim is billed in.

Where the observability gap actually is

The initial-access story in this case is a real one — an internet-exposed personal instance with a fail-open Google-auth path is a first-order finding — but the more interesting failure is downstream. The credential leaves the app. The credential is used from an unexpected place, at an unexpected volume, on unexpected models, for three weeks. Nobody watching the account raises a hand.

That is a runtime observability gap, not a credential-hygiene gap. Rotating the key after the fact is remediation. Catching the moment when the workload signature on that key stops matching the workload signature of the org it belongs to is the control that closes the three-week window.

METR's post is unusually candid about this. The remediation set was the correct one — revoke researcher access, rotate credentials, wipe the laptop, notify the model developer, add spend alerts where possible — but the detection was outsourced. If the model provider had not surfaced it, the meter would still be running.

The takeaway

Two things fall out.

First: long-lived AI API keys are now a first-class monetizable target, and the primary abuse pattern is quiet inference consumption, not data exfiltration or lateral movement. The Anthropic disclosure and the METR disclosure are the same market fact viewed from two angles — one at the per-user session layer, one at the per-org billing-key layer.

Second: the workload on an AI account is now the security signal. Vendor-side session revocation, spend caps, and free-credit-key controls all help after the fact. What has to move is the ability to notice that an account is doing work its owner did not authorize, in something closer to hours than weeks. That observable does not live in the CVE feed, and it does not live in the vendor's fraud console. It lives at the runtime boundary of the account itself.

METR handled the disclosure the right way — publicly, with the mechanism named, with the failure modes stated plainly. The uncomfortable part of the story is that even a security-sophisticated AI-eval organization, staring at its own model traffic every day, could not tell its own workload from an attacker's for three weeks.

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.