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 [7]. That check failed open and silently stopped authenticating, which left the agent orchestration dashboard reachable for several days [8]. 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 [10].
Three weeks at roughly $600,000 works out near $200,000 a week, about $28,600 a day, on one key [1]. 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 [12]. 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 [9]. Nothing is attributed to a known actor or group [4]. METR also states that no AI agent broke into its evaluations [5]. 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 [15].
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 [16], and the database behind it had accidentally picked up sensitive model data it was never meant to hold [17]. METR learned of that from an independent security researcher and took the API offline [18]. Its log review concludes the attackers probed the endpoint in passing and never discovered the exploit [19]. 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 [13]. 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 [1].
