Stolen METR Key Handed Attackers Nearly $600,000 in AI Resources

Translated by a model; the original is in Russian.

· Security
METR, a nonprofit that evaluates frontier AI models, has disclosed two incidents: attackers made off with an API key and burned through someone else's compute credits, and later methodically probed its infrastructure.

cover.svg

METR (Model Evaluation and Threat Research), a research nonprofit that tests frontier AI models for their ability to carry out long autonomous tasks, has reported two notable security incidents. By its assessment, the attackers gained no access to sensitive information; a version of the report was shared in advance with the AI companies METR works with. The attacks have not been attributed to any known group, and — importantly — this is not a case of AI agents escaping evaluation on their own.

The March incident

One of the researchers, who had no access to secret data, was running agents on a personal EC2 instance that was deliberately exposed to the outside world but sat behind Google authentication. On the machine was an API key for METR's shared account for public models. The trouble lay in a “hastily assembled” application: a fail-open vulnerability silently disabled authentication, and the agent control panel hung out on the open internet for several days.

As METR tells it, the attacker was apparently hunting for such freshly created sites through Certificate Transparency logs, cherry-picking targets by keywords like “LLM” and “agents” in hopes of harvesting provider keys left unattended. Having found the system, they simply asked the agent to cough up the API key, added their own SSH key for persistence, and spent three weeks burning through someone else's credits on public models.

The bill would have come to roughly $600,000 had the compute not been provided to METR for free (the provider is not named). The abuse went unnoticed for so long for a rather mundane reason: the organization already runs large-scale experiments that devour huge volumes of tokens, and there were simply no spending limits in place. After the incident, METR tightened its rules on placing keys and data on third-party infrastructure, improved monitoring, and where possible added spending alerts.

The May incident

The second story is no longer an accidental leak but a “sustained external campaign,” likely mounted by a financially motivated actor looking to reach frontier models. The attackers made heavy use of agents to automatically search for vulnerabilities: they brute-forced credentials at authentication providers, tried to obtain OAuth tokens, scanned new services, and sent phishing to employees.

Around the same time, METR inadvertently exposed a “read-only” SQL query mechanism built into its public transcript viewer. By default, queries were restricted to public data, but because of a bug the component could in theory reach unpublished evaluation results. Worse still, data for sensitive models had “accidentally” ended up in the database, which was supposed to hold only non-secret material. This came to light only after an independent researcher found and reported the problem, at which point the API was shut down. According to the available information, the attackers briefly probed this endpoint, but there is no sign that they discovered the vulnerability or reached the restricted data.


Source: The Hacker News

Comments

Sign in, to comment.

  • No comments yet.