“In March 2026, attackers stole an API key for inference on public models and consumed a substantial amount of credits,” METR disclosed — a brief sentence that, in the span of three weeks, describes roughly $600,000 of model-usage credits drained from a nonprofit’s account before anyone realised.
How the March API-key theft unfolded
METR says the March incident began with a researcher running agents on a personal EC2 instance that was "intentionally" left publicly accessible behind Google authentication. That instance contained an API key for METR’s public models account. A "vibe-coded app" on the instance contained a fail-open bug that disabled authentication and exposed the service to the public internet for several days.
According to METR’s account, the attacker appears to have found the app by searching recently-registered sites — for example, via certificate transparency lists — hunting for vibe-coded sites with high-signal keywords related to LLMs or agents in order to harvest exposed model-provider API keys. Once the attacker located the app, they prompted an agent to reveal its model-provider API key, added an SSH key to maintain persistent access, and over the next three weeks used the stolen credentials to consume API credits on public models worth about $600,000. METR notes that the unnamed model developer had given the credits to the nonprofit for free.
METR reported no evidence that attackers accessed sensitive information in this incident, and it investigated the breach with security experts.
Why roughly $600,000 of usage went unnoticed
METR’s report addresses what many will find the most surprising detail: how large, sustained illicit usage could proceed for weeks without triggering alarms. The organisation highlights three practical reasons.
- High-volume testing baseline: METR regularly runs evaluations that use large numbers of tokens; the organisation is "very acclimated to getting lots of weird rate limit and API errors," so elevated or unusual usage did not initially appear anomalous.
- Credits were free: Because the tokens used were donated, METR did not see a large bill that might have spurred immediate investigation.
- No spending limits on keys: At the time of the incident there was no way to place spending limits on keys like the one that was stolen, removing a straightforward technical guardrail.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildMay 2026: probing, agents, and an exposed transcript viewer
In early May, METR observed a separate, sustained external attack campaign. The organisation says it was "tipped off" that attackers who appeared financially motivated might be trying to gain illicit access to frontier models. METR watched intruders systematically probe its publicly accessible infrastructure using agents that performed automated vulnerability discovery, credential stuffing against authentication providers, attempts to obtain OAuth token grants, scans of newly deployed services, and phishing attempts.
Concurrently, METR unintentionally exposed a read-only SQL query mechanism via its public transcript viewer. Although queries were scoped to public data by default, a bug allowed access to unpublished evaluation data, and METR acknowledged that "some sensitive model data was accidentally included in this database." METR reports there is no evidence the attacker found that exploit or accessed any non-public data.
An independent bug hunter discovered the vulnerability and reported it to METR; METR paid the researcher a bounty and took the API offline.
METR’s remediation steps and follow-up work
METR says it investigated both incidents alongside security experts and has implemented a series of changes. The organisation reports improvements to its security infrastructure, protocols, and review processes; it has hired a security lead and plans to add more security staff. METR also moved to use an isolated production environment for public-facing applications, separate from internal infrastructure.
METR researchers are continuing cross-organisational work: the group worked with OpenAI to investigate how OpenAI’s agents hacked Hugging Face, and it says it will continue to invest in security.
How technologists, model developers, and threat actors are likely to react
- Technologists and security teams: The fail-open bug, the presence of an API key on a publicly accessible personal instance, and the lack of spending limits on donated credits are concrete failure modes. Teams will likely prioritise environment isolation, stricter code-review guardrails for "vibe-coded" or prototype apps, and token governance.
- Model developers and providers: The fact that donated, free credits were consumed at scale without creating a billing signal highlights how credit programs can be abused. Providers and developers may reexamine how credits are issued, monitored, and rate-limited.
- Adversaries and opportunistic actors: METR observed attackers employing agents and a toolkit of automated discovery, credential stuffing, OAuth token attempts, scanning, and phishing. The record shows how those techniques can be combined to harvest keys and persist via SSH once a single exposed resource is found.
METR’s disclosure is blunt about the proximate causes — an exposed key, a fail-open authentication bug, and production and observability gaps — and explicit about the fixes it has taken: bounty payments, isolation of public-facing services, new security hires, and procedural changes. METR found no evidence of sensitive-data access in either incident and has pledged continued investment in security. Whether the broader ecosystem will tighten controls on donated credits and default key limits remains an open operational question for model developers and infrastructure providers.
