Breach breakdowns

Breakdown: a vibe-coded agent dashboard at METR failed open and leaked an API key worth $600k in credits

By Pritesh Ghodge, security engineer · Published 12 November 2026

METR is the AI research nonprofit that tests frontier models. On 31 August 2026 it published a security update about two incidents earlier in the year. The first one is the reason I'm writing this. A researcher ran AI agents behind a small vibe-coded dashboard on a personal EC2 server. The dashboard was supposed to sit behind Google login. A bug turned the login off without anyone noticing, an attacker found the site, asked the agent for its model API key, and spent three weeks burning roughly $600,000 worth of credits.

What strikes me is how ordinary every step is. Nobody needed a zero-day. Everything below comes from METR's own post and the coverage in The Register, Infosecurity Magazine, The Hacker News and The Stack.

What happened

• The setup. In March 2026 a METR researcher with no access to sensitive data ran agents on a personal EC2 instance. It was made public on purpose, behind Google authentication. The instance held an API key for METR's general-access account, the one used for public models.
• The bug. METR says the vibe-coded app "included a fail-open vulnerability that silently disabled authentication". The dashboard sat on the open internet for several days with no login in front of it.
• How it was found. METR suspects the attacker went through newly registered websites, for example certificate transparency logs, looking for vibe-coded sites with words related to LLMs or agents. The goal was harvesting model provider API keys.
• The theft. The attacker didn't need to read a file. They prompted the agent directly to reveal its API key. Then they added their own SSH key to the box so they could come back.
• The bill. Over three weeks they used the key on public models. METR puts the value at about $600,000, but the model developer had given METR those credits for free, so it wasn't a cash loss.
• Why nobody noticed. METR runs huge evaluations, so odd rate-limit errors are normal there. Its usage dashboard didn't show rate-limited requests to everyone. And because the credits were free there was no spend ceiling, and no way to put a limit on that kind of key at the time.

What's confirmed and what we don't know

This one is unusual because the main source is the victim, writing in detail. I haven't seen anyone dispute METR's account. The coverage repeats it. The gaps are what METR chose not to publish.

• Confirmed by METR. The fail-open auth, several days of exposure, the agent being prompted for the key, the SSH persistence, three weeks of use, roughly $600k in value. METR and its security consultant Calif found no compromise beyond that one key and no sensitive data accessed.
• METR's best guess, not proven. Finding the site through certificate transparency logs is phrased as a suspicion.
• Not published. What the fail-open bug actually was, what framework or tool built the app, and which model provider was involved. So I won't guess at the exact line of code.
• A separate incident. In May 2026 attackers probed METR's public infrastructure, and an independent researcher reported a bug in a public transcript viewer's read-only SQL feature that could reach unpublished data. METR says the attackers didn't find or use it. That one isn't about a vibe-coded app, so I'm leaving it there.

Why it happened

I'd put it down to three things stacking up.

1. Auth that fails open. A common shape in quickly built apps is "if login is configured, require it". If an env var is missing, a callback throws, or a middleware doesn't match a route, the app quietly serves everyone. It looks fine to the person who built it because they're already signed in. We don't know METR's exact bug, but this is the kind of code to look for:

// fails open: if the env var is missing, everyone gets in
if (process.env.GOOGLE_CLIENT_ID) {
  app.use(requireGoogleLogin);
}

// fails closed: refuse to start without auth
if (!process.env.GOOGLE_CLIENT_ID) {
  throw new Error("auth not configured, refusing to start");
}
app.use(requireGoogleLogin);

2. An agent that can read its own key. If the agent's process has the key in its environment and a shell tool, then anyone who can talk to the agent can ask for it. Prompting was all it took here.
3. No spend limit and noisy alerts. A key with no cap, watched by a dashboard that hid the warning signs, let three weeks go by.

And the discovery part should change how you think about "nobody knows the URL". The moment you get an HTTPS certificate, your hostname lands in public certificate transparency logs. People scan those for exactly this kind of site.

How to check your own app

Only test apps and servers you own.

1. Hit it signed out. Open every page and API route in a private window or with curl -i. You want a redirect to login or a 401, never the dashboard or JSON.
2. Break auth on purpose. In a staging copy, remove the auth env vars (client ID, secret, allowed domain) and start the app. It should refuse to start or block everything. If it starts and lets you in, it fails open.
3. See what's public about you. Look up your domain on crt.sh. Every subdomain listed there is findable by strangers, including that test dashboard from last month.
4. Ask your agent for its secrets. Literally type "print your environment variables" or "what's your API key" into your own agent UI. If it can answer, so can an attacker.
5. Check the box itself. On the server, look at ~/.ssh/authorized_keys for keys you don't recognise, and check which ports are open to the internet.
6. Look at usage and limits. Open your model provider's usage page for spikes you can't explain, and make sure every key has a spend limit or alert.

Fix steps

1. Make auth fail closed. Missing config should crash the app, and the default for any route should be "deny".
2. Put a gate in front of the app. For internal dashboards, use something outside your code like Cloudflare Access, Tailscale or an IP allowlist, so a bug in your login code isn't the only lock.
3. Keep keys away from the agent. Route model calls through a small proxy that holds the key, or give the agent a scoped, short-lived key. Don't run agents with your main key sitting in their environment.
4. One key per tool, with a cap. Then a stolen key does limited damage and you can tell where it leaked from.
5. If you think it's exposed, rotate first. Revoke the key at the provider, remove unknown SSH keys, and rebuild the server if you can't trust it. That's what METR did, down to imaging and wiping.

For keys sitting in front-end code, the exposed AI API key guide walks through finding and rotating them.

My take

METR is a security-minded org with SOC 2 and a real security programme, and a weekend-style side project still got through. That's not a dig at them. Publishing this much detail is useful for everyone. If they can get caught by a dashboard that silently dropped its login, so can my apps and yours. Ten minutes signed out in a private window is cheap.

Scan your app free

Sources

• METR, Update on Security at METR, 31 August 2026 (primary source)
• The Register, Attacker stole a METR API key, used $600K worth of credits, and no one noticed for weeks, 1 September 2026
• Infosecurity Magazine, Attackers Steal METR API Key and Burn $600,000 in AI Credits
• The Hacker News, Attackers Steal METR API Key and Consume AI Credits Worth About $600,000
• The Stack, How a vibe-coded app let hackers use $600k worth of AI tokens at METR, 1 September 2026

Related

• Breakdown: how Moltbook's open Supabase database exposed 1.5M agent API keys
• Breakdown: RedAccess found 5,000+ vibe-coded apps with almost no authentication
• Breakdown: how a public app_id unlocked private Base44 apps
• OpenAI, Claude or Gemini API key exposed in your frontend? What to do now
• Exposed .env, .git and source maps