Attackers talked a METR researcher's agent out of its inference API key
METR's inference key sat on a researcher's personal EC2 instance, and the agent handed it over when asked. The three-week burn would have cost about $600,000 if the model provider had not donated the credits.
The Watch · Security desk
What happened
- The AI evaluation non-profit METR disclosed two notable security incidents in which external actors attempted to gain unauthorized access to its systems.
- A researcher's personal EC2 instance, made public behind Google authentication, ran a prompt-generated app whose fail-open bug silently disabled that authentication and left the agent dashboard exposed for several days.
- METR says the usage would have billed about $600,000 had the model provider, which it did not name, not supplied the credits to the non-profit for free.
- METR describes separate May 2026 activity as a sustained campaign by a likely financially motivated actor trying to obtain unlawful access to frontier AI models.
Why it matters
- Who's exposed exposure A researcher with no sensitive access still holds a spend-capable credential, which puts personal cloud accounts inside the blast radius while they stay outside the asset inventory anyone rotates keys against.
- What it limits constraint A lab whose normal traffic is enormous cannot detect credential theft by spend anomaly, so a hard per-key ceiling becomes the only control capable of firing within hours.
- What's now possible capability Certificate transparency gives key hunters a rolling feed of newly stood-up agent apps, compressing the search for exposed provider keys into the days such a dashboard stays online.
- What it costs cost The loss fell on the model provider rather than the non-profit, which means the party best placed to impose default per-key caps is also the one currently absorbing the bill.
Next story · Invest · Oct 2
OpenAI fires three safety researchers for allegedly mishandling sensitive informationConfirmed14 publishers
The key lived in the agent's own context, so the only thing between the public internet and METR's general-access inference account was a Google authentication check inside an app the researcher had generated by prompting [5]. That check failed open and silently stopped authenticating, which left the agent orchestration dashboard reachable for several days [6]. From there the attacker needed no vulnerability in anything: it prompted the agent to reveal the model provider key, then added an SSH key to the instance to keep the access [7].
Three weeks at roughly $600,000 works out near $200,000 a week, about $28,600 a day, on one key [20]. METR says the spend was not caught quickly because its own evaluations routinely consume high token volume and the key had no cap on spend [9]. That daily rate disappeared into a line item where much larger numbers are ordinary.
On how the box was found, METR marks its own reasoning as suspicion rather than evidence: it thinks the attacker trawled recently registered domains, including certificate transparency lists, for LLM and agent keywords likely to front exposed provider keys [19]. Nothing is attributed to a known actor or group [14]. METR also states that no AI agent broke into its evaluations [16]. The agent use that matters in May is the attacker's own, where METR says the operators automated vulnerability discovery with agents alongside credential stuffing against its authentication providers, OAuth token grant attempts, scans of newly deployed services, and attempts to phish staff [12].
May also produced the second detection failure. A read-only SQL query mechanism in METR's public transcript viewer was scoped to public data by default, but a bug in it could have been exploited to reach unpublished evaluation data [13], and the database behind it had accidentally picked up sensitive model data it was never meant to hold [15]. METR learned of that from an independent security researcher and took the API offline [17]. Its log review concludes the attackers probed the endpoint in passing and never discovered the exploit [18]. That read is METR's own, and no contrary account has been published.
The fixes METR lists are the expected ones: updated policy on putting its credentials or data on non-METR infrastructure and devices, improved monitoring, and spend alerts added to keys where possible [10]. The hedge at the end of that list is where the residual risk sits. Not every provider hands a research account a per-key spend alert, and the March theft ran twenty-one days in exactly the gap that hedge describes [20].
What to watch
- Whether the unnamed model provider starts defaulting research and non-profit keys to hard spend caps rather than alerts.
- Whether the same operator surfaces at other evaluation labs using the same agent-driven probing and credential stuffing.
- Whether METR publishes indicators for the certificate transparency harvesting it says it suspects.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence70
- Adoption
- Not scored
- Hype gap+20
- Incentives50
- Confidence68
Perspective Coverage
4 publishers- Builder
- Builder 33%
- Operator
- Operator 56%
- Investor
- Investor 11%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
METR (Model Evaluation and Threat Research) is a research non-profit that evaluates frontier AI models for their ability to carry out long-horizon, agentic tasks.
- [2]
METR disclosed that it suffered two notable security incidents in which external actors attempted to gain unauthorized access to its systems.
- [3]
METR says no sensitive information is believed to have been accessed as a result of the incidents, and that a version of its findings was shared with the AI companies it works with before public disclosure.
- [4]
In March 2026, attackers stole an API key for inference on public models and consumed a substantial amount of credits, according to METR.
- [5]
A METR researcher with no sensitive access ran agents on a personal EC2 instance that was intentionally made publicly accessible behind Google authentication; the instance contained an API key for METR's general-access (public models) account.
- [6]
The vibe-coded app on the instance had a fail-open vulnerability that silently disabled authentication, exposing the agent orchestration dashboard to the public internet for several days.
- [7]
The threat actor prompted an agent directly to reveal its model provider API key, added an SSH key for persistent access, and used the stolen credentials to consume API credits on publicly available models over a period of three weeks.
- [8]
METR says the accrued credits would have amounted to approximately $600,000 in bills had they not been provided to the non-profit for free by the model provider, which METR did not name.
- [9]
METR says the illicit usage was not immediately caught because it runs large-scale evaluations and experiments that typically consume a high volume of tokens, and because there were no caps on token spend.
- [10]
After the March incident METR updated its security policies around putting METR credentials or data on non-METR infrastructure or devices, improved monitoring, and added spend alerts to keys where possible.
- [11]
METR describes the May 2026 activity as a sustained external attack campaign by a likely financially motivated threat actor seeking unlawful access to frontier AI models.
- [12]
METR says the May attackers systematically probed its publicly accessible infrastructure with heavy use of agents to automate vulnerability discovery, including credential stuffing authentication providers, attempting OAuth token grants, scanning newly deployed services, and attempting to phish staff.
- [13]
METR inadvertently exposed a read-only SQL query mechanism built into its public transcript viewer; queries were scoped to public data by default, but a bug in the component could have been exploited to access unpublished evaluation data.
- [14]
The attacks have not been attributed to any known threat actor or group.
- [15]
The database behind that query mechanism accidentally included sensitive model data, despite being supposed to contain only data from non-sensitive models.
- [16]
METR says the incidents did not involve AI agents breaking into its evaluations.
- [17]
METR became aware of the exposed query mechanism only after an independent security researcher discovered and reported it, and the API was then taken offline.
- [18]
METR says the attackers probed the transcript viewer endpoint in passing as part of their broader campaign, and that the evidence shows no indication they discovered the exploit or accessed any non-public data.
- [19]
METR says it suspects the attacker found the instance by looking through recently registered websites, for example in certificate transparency lists, for vibe-coded sites with high-signal keywords relating to LLMs or agents, in order to harvest potentially exposed model provider API keys.
- [20]
The stolen key ran roughly $200,000 a week, about $28,600 a day, across the 21 days of the three-week theft.
Sources
4 independent publishers whose own reporting we read for this story.
- infosecurity-magazine.comAttackers Steal METR API Key and Burn $600,000 in AI Credits
1 article · September 1, 2026
- metr.orgUpdate on Security at METR
1 article · September 2, 2026
- scworld.comMETR discloses 2 security incidents, including $600,000 model credit theft
1 article · September 2, 2026
- thehackernews.comAttackers Steal METR API Key and Consume AI Credits Worth About $600,000
2 articles · September 1, 2026