METR Blew $600K of Free AI Credits on One Fail-Open Auth Bug (Their Own Postmortem)

The incident in one paragraph//

In March, a METR researcher with no sensitive access ran agents on a personal EC2 instance intentionally made publicly accessible behind Google authentication. The app was vibe-coded and included a fail-open vulnerability that silently disabled authentication — so the system sat exposed to the public internet for several days. An attacker found it, prompted an agent directly until it revealed its model-provider API key, added their own SSH key for persistence, and over three weeks burned through credits worth about $600,000.

The catch: those credits had been granted to METR for free by the model developer. There was no bill. That's why nobody noticed for a month. (The $600K is the value of what was consumed — keep that distinction in mind, because "no invoice" is exactly how it slipped past everyone.)

How the attacker found it (the part that should worry you)//

METR suspects the attacker wasn't brute-forcing anything. They were scanning certificate-transparency lists for recently registered websites, filtering for vibe-coded sites with high-signal keywords about LLMs or agents — specifically hunting exposed model-provider API keys. Your agent dashboard's TLS cert is a public advertisement that says "AI stack, fresh deploy, probably sloppy."

Why nobody noticed (read this twice)//

Straight from METR's own postmortem:

1. They run evaluations and experiments that use large volumes of tokens, and are used to getting lots of weird rate-limit and API errors — many of them spurious. The noise floor is so high that a stranger hammering your keys looks like normal eval traffic.
2. At the time, their internal usage dashboard didn't show data on rate-limited requests for all users, even when they were occurring.
3. Because the tokens were free, there was no natural spend ceiling — and as of the incident, no way to put a spending limit on a key like this one.

The May near-miss (same lab, second incident)//

Early May: a sustained external attack campaign, with METR tipped off that financially motivated hackers may have been looking for frontier-model access. The attackers systematically probed public infrastructure with agents automating vulnerability discovery — credential-stuffing auth providers, attempting OAuth token grants, scanning newly deployed services, phishing staff.

Meanwhile, METR had inadvertently exposed a read-only SQL query mechanism via their public transcript viewer. Queries were scoped to public data by default, but a bug could be exploited to reach unpublished evaluation data — and some category-3 (sensitive) model output was accidentally in that database. An independent security researcher found it first, disclosed responsibly, and got paid the bounty; METR took the endpoint offline. The attackers had probed the endpoint "in passing" — no evidence they discovered the exploit or accessed any non-public data.

METR's assessment of both incidents: near-misses — to their knowledge, no category 3–4 sensitive data was accessed (though some cat-3 data was accessible in principle; their bar for "accessed" is discovering and exploiting the bug, then downloading without triggering errors, which they consider highly unlikely).

What METR changed//

Incident response: revoked all access for the researcher, stopped and imaged the instance, rotated all present credentials, imaged and wiped the laptop, alerted the partner AI company. Security consultant Calif validated the findings and ran its own compromise assessment; manual and agent-assisted forensics confirmed the scope was a single stolen API key. Then the structural changes:

• Formalized a security review process for any researcher publicly deploying applications
• Expanded policies on putting METR credentials or data on non-METR infrastructure/devices
• Added spend alerts to keys where possible, increased monitoring coverage, and worked to kill "noise" alerts
• Now maintains an isolated public production environment architecturally separated from internal infra, so a misconfiguration in a public service can't reach internal data
• Shorter credential longevity, more logging (database queries, API usage), additional endpoint/server security software, reduced permission scopes — and they hired a security lead

What to check tonight//

1. Find what you've exposed. Check your domain/cert in a certificate-transparency monitor (or just scan your public IP) — if an agent dashboard or model API is out there, it's advertising itself with keywords.
2. Make auth fail closed. Test with a deliberately bad token: if the request still gets through, you have METR's bug. Fail-open usually means a try/catch that swallows the auth exception and returns 200 anyway — "on error, let them in."
3. Put a ceiling on every API key. Spend alerts at minimum; hard caps where the provider supports it. Free credits are exactly how $600K disappears without an invoice.
4. Audit authorized_keys on anything public — METR's attacker added an SSH key for persistence before anyone noticed. A public box with no spend ceiling and one extra SSH key is a compromise, not a close call.
5. Don't put lab keys on personal boxes without rotation + a ceiling. The researcher in question had "no sensitive access" — but the general-access key was enough to buy $600K of inference.