Security • 5 min read
AI evaluator METR disclosed a $600,000 API-credit theft and a separate database flaw that could have exposed unpublished model evaluations.
Image: Dark Reading METR, a nonprofit that evaluates frontier AI systems, disclosed two security incidents on August 31, 2026: attackers spent three weeks using a stolen API key, and a separate public-facing database flaw could have exposed unpublished evaluation data.
METR said its investigation found no evidence that either incident exposed sensitive information, and no evidence that AI agents hacked third parties during its evaluations. But the first incident was a successful credential compromise, not merely an attempted breach: an attacker obtained an API key, established persistence on the affected system and consumed model credits for weeks.
METR works with major AI model developers, including OpenAI, Anthropic, Google, Meta and Amazon. Its systems can contain evaluation results, access to nonpublic models and confidential information about AI systems. The organization said its response included new security hiring, tighter network separation, more logging and reduced credential permissions.
Recommended reading
Critical Artifactory flaw is already under attack
Sophia Reynolds • • 5 min read
How the two incidents unfolded #
The March compromise began with an employee’s personal Amazon EC2 instance. A researcher who did not have access to METR’s sensitive categories used an agent orchestration application on the instance. The application had been intentionally placed behind Google authentication, but a fail-open authentication bug silently disabled that protection and left the system exposed to the public internet for several days.
METR suspects the attacker found the instance by searching recently registered websites, including certificate-transparency listings, for terms associated with large language models and agents. After locating the system, the attacker prompted an agent to reveal the model-provider API key, added an SSH key for persistent access and used the credentials for approximately three weeks.
The key belonged to METR’s general-access account for public models. The consumed credits would have been worth approximately $600,000, although the model developer had provided them to METR at no charge. METR said the stolen key was not authorized to access private models or hidden chain-of-thought data.
| Date | Incident and confirmed scope | METR’s response |
|---|---|---|
| March 2026 | Fail-open authentication on a personal EC2 instance exposed an API key; attacker used it for about three weeks and consumed credits worth approximately $600,000 | Revoked the researcher’s access, stopped and imaged the instance, rotated credentials, wiped the researcher’s laptop, and added monitoring and spend alerts where possible |
| Early May 2026 | Attackers ran a sustained campaign involving credential stuffing, OAuth-token attempts, service scans and phishing; a public transcript viewer also exposed a read-only SQL mechanism that contained a bug capable in principle of reaching unpublished data | Took public services offline, isolated public production from internal systems, removed the vulnerable API and commissioned additional red-team testing |
METR attributed the delayed detection to a monitoring gap rather than a lack of traffic. The organization was accustomed to large token volumes and frequent rate-limit errors during evaluations. Its usage dashboard did not show rate-limited requests for all users, and the account had no spending ceiling because METR was not paying for the tokens. That combination made unusual usage harder to distinguish from normal evaluation activity.
“Although these incidents had limited consequences, we considered them near-misses, and increased our security investment in response.”
The database flaw was not just a theoretical exposure #
During the early-May attack campaign, METR’s public transcript viewer inadvertently exposed a read-only SQL query mechanism. Queries were scoped to public data by default, but a bug could be exploited to retrieve unpublished evaluation data. The database was intended to contain only category 2 material—unpublished results and outputs involving public models—but METR discovered that some category 3 data had also been included accidentally.
An independent security researcher found and responsibly disclosed the vulnerability. METR took the API offline and paid a bounty. The attackers had probed the endpoint while conducting broader reconnaissance, but METR said there was no evidence they found the exploit or accessed nonpublic data.
METR’s category 3 controls cover evaluation results or outputs from private models, hidden chain-of-thought data, and credentials that grant access to nonpublic models or models without production safeguards. Category 4 includes intellectual property and business information such as model architectures, training processes, release dates and internal incidents.
METR said no category 3 or category 4 data was accessed to its knowledge. However, some category 3 output data was inadvertently accessible in principle. The organization said exploiting the issue would have required an attacker to discover the bug, identify the sensitive transcripts and download them without triggering errors, which it considers highly unlikely.
The database was not clean: the public application had an access path toward data that should have been behind stronger isolation, and its contents did not fully match their intended classification.
METR’s security changes #
After the March incident, METR formalized security reviews for researchers who publicly deploy applications and expanded policies covering company credentials and data on non-METR infrastructure or devices. It also improved monitoring, worked to eliminate noisy alerts and added spend alerts to keys where the provider supported them.
After the May campaign, METR created an isolated public production environment architecturally separated from internal infrastructure. The goal is to ensure that a mistake in a public application cannot directly expose internal data. The organization also shut down legacy infrastructure that expanded its attack surface and commissioned additional testing from its external cybersecurity partner, Calif.
METR hired a security lead and plans to hire a full-time security engineer. It said it increased logging across database queries and API use, added monitoring for unusual API-key activity, deployed additional endpoint and server security software, shortened credential lifetimes and reduced permission scopes. Those measures were accurate as of July 30, 2026 and may change.
METR organizes company information into four categories. Categories 3 and 4 are protected by information barriers, while researchers working with categories 1 and 2 face fewer restrictions. This limits access to private-model material without applying the same controls to every experiment involving public models. The incidents show the risk in that arrangement: low-sensitivity research infrastructure can still carry valuable credentials, while a public viewer can become a route toward more sensitive records.
“We have conducted an initial scan of our evaluations, and currently have no evidence of any agents hacking third parties during our evaluations. We will share a more detailed update on this soon.”
The disclosure concerns conventional security failures around AI work, not evidence that an evaluation agent escaped into external systems. A personal cloud deployment, missing usage ceilings, noisy telemetry and an insufficiently isolated public database created two serious near-misses. METR’s next detailed review of its evaluations is still pending, and its current statement does not provide independent evidence that the stolen key or database flaw was used to access private model systems.
Frequently asked questions #
What did attackers steal from METR?+ #
Attackers obtained an API key for METR’s general-access account for public AI models. They used it for about three weeks to consume model credits worth approximately $600,000.
Was METR’s sensitive evaluation data accessed?+ #
METR said it has no evidence that category 3 or category 4 data was accessed. Some category 3 output data was inadvertently accessible in principle through a database flaw.
Did AI agents hack third-party systems during METR evaluations?+ #
METR said its initial scan found no evidence that agents hacked third parties during its evaluations. It plans to publish a more detailed update.
Sophia Reynolds Security Editor
Sophia unpacks the invisible wars happening on our networks. Covering cybersecurity, privacy legislation, and cryptography, she exposes how our data is weaponized and defended. Before joining for(geeks), she spent years as a penetration tester. She's the reason the rest of the team uses physical security keys.