METR discloses API key theft after three weeks of abuse

METR, the nonprofit that runs independent evaluations of frontier AI models, disclosed two security incidents from earlier this year in a security update posted on August 31. This is METR's own account, not a breach at a model provider. The headline incident: in March, attackers stole an API key and ran up heavy usage over roughly three weeks before anyone noticed.

The credits behind that key would have been worth about $600,000. They cost METR nothing directly, because the model developer had donated them with no spending limit attached, which is exactly why there was no invoice ceiling to trip an alarm.

The key lived on a researcher's personal EC2 instance running an agent dashboard. A fail-open bug silently disabled the Google sign-in in front of it for several days, and once the dashboard was exposed, the attacker got the provider key out of it and added SSH access to hold the foothold. METR says the abuse blended into normal, high eval token volume and slipped through gaps in its monitoring, and the donated key had no spend limit to cap the loss.

On how the box was found, METR says it suspects the attacker "found the instance by looking through recently-registered websites (e.g. in certificate transparency lists)." That is the organization's suspicion, not confirmed attribution, and no threat actor is named.

A second, quieter incident in May

METR also describes sustained probing of its public infrastructure in May. A separate bug, an exposed SQL query path in a transcript viewer, could have reached unpublished evaluation data including some sensitive model material. An independent researcher disclosed that path, and METR says attackers were probing but there is no evidence they found or used it.

"To the best of our knowledge, no data from categories 3 or 4 was accessed as a result of these incidents," METR wrote, referring to its most sensitive data tiers.

What METR changed

The response is a familiar cleanup: revoke the researcher's access, image the instance and the laptop, rotate credentials, add spend alerts, and hire a security lead. The structural fix is the one to copy, an isolated public production environment separated from internal systems, plus a formal security review before anything public ships. It is the same first-party-disclosure posture we saw in OpenAI's Hugging Face incident report: own the timeline, name the gap, publish the fixes.

The takeaway

If your teams run agent demos or eval dashboards on personal cloud accounts with shared or donated API keys, treat this as the pattern to ban tonight. Put spend caps and alerts on every key, donated ones included, require an authentication review before any internet-reachable agent dashboard goes live, and keep production and eval data off researcher-owned machines.