Please note that this post focuses on incidents where external actors attempted to gain unauthorized access to METR’s systems, not AI agents hacking in our evaluations. 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.

METR had two notable security incidents earlier this year. Following a thorough investigation in collaboration with our security consultants, we believe no sensitive information was accessed in either of these incidents. Nonetheless, we believe it is valuable to share information about how these incidents look in practice and the steps we took as a result.

In March 2026, attackers stole an API key for inference on public models and consumed a substantial amount of credits. In May 2026, we observed attackers systematically probing our publicly accessible infrastructure, including an unsuccessful attempt to access internal data via an inadvertently exposed endpoint. Although these incidents had limited consequences, we considered them near-misses, and increased our security investment in response.

Our approach to security

METR handles sensitive data as part of our core work, including nonpublic model access and confidential information, so we have invested accordingly in our security posture. Our historical security controls are described in more detail on our blog, and contributed to our SOC 2 Type I certification.

Our general organizing principles are:

1. centralized identity management with strong authentication requirements,
2. strong network isolation,
3. minimal permission scoping (including information barriers for sensitive information),
4. monitoring across platforms for indicators of attack or compromise.

We work with four major categories of company data. They are, from least to most sensitive:¹

1. Published: Data we expose publicly (e.g. published transcripts or evaluation results),
2. Generic model access:
   1. Data: Unpublished evaluation results involving only public models and information (e.g. a new version of our time horizon estimates (TH1.1) based on historical models), or outputs (e.g. agent transcripts) from public models.
   2. Credentials: API keys granting access to public models
3. Sensitive model access:
   1. Data: Evaluation results and outputs from private models or including hidden chain-of-thought (CoT)
   2. Credentials: API keys granting access to hidden CoT, non-public models, or models without production safeguards.
4. Highly sensitive information: Sensitive IP or business information, such as information about architectures and training processes, release dates, or internal incidents.

Our security protocols are designed to keep sensitive data (categories 3 and 4) tightly controlled behind information barriers, while minimizing friction for researchers working with less-sensitive data (categories 1 and 2).

To the best of our knowledge, no data from categories 3 or 4 was accessed as a result of these incidents. However, some sensitive model output data (3.a) was inadvertently accessible in principle, although we believe it was not accessed by the attackers.

Incident 1: Agent orchestration dashboard allowed theft of an API key for public models

Summary

In March 2026, one of our researchers with no sensitive access (e.g., no access to data or credentials in categories 3 and 4) used agents running on a personal EC2 instance intentionally made publicly accessible behind Google authentication. This EC2 instance contained an API key for METR’s general-access (public models) account. The vibe-coded app included a fail-open vulnerability that silently disabled authentication, which led to the system being exposed to the public internet for several days.

From our analysis, we suspect that the attacker found the instance by looking through recently-registered websites (e.g. in certificate transparency lists) to find vibe-coded sites with high-signal keywords relating to LLMs or agents, for purposes of harvesting potentially exposed model provider API keys.

Upon finding the deployed system, the attacker prompted an agent directly to reveal its model provider API key, added an SSH key for persistent access, and over the course of three weeks used the stolen credentials to consume a significant amount of API credits on publicly-available models. These credits would have been worth approximately $600,000, although the model developer had granted them to METR for free.

Why didn’t we notice the large illicit usage?

1. We are accustomed to running evaluations and experiments that use large volumes of tokens; in particular, running large-scale evaluations with pre-deployment models means we are very acclimated to getting lots of weird rate limit and API errors, many of which are spurious and don’t actually reflect high usage.
2. At the time of the incident, our internal usage dashboard didn’t show data on rate-limited requests to all users, even if they were occurring.
3. Because we were not paying for these tokens, there was no natural token spend ceiling, and as of the incident there was no way to put a spending limit on keys like this one.

Response

1. After we recognized that the large increase in model usage was not part of an evaluation, we located the compromised personal instance as the source. We immediately revoked all access for the researcher, stopped and imaged the instance, rotated all present credentials, and imaged and wiped their laptop. We alerted the relevant partner AI company and kept them updated on our incident response.
2. Our security consultant (Calif) validated our findings and did its own compromise assessment. We also did manual and agent-assisted forensics to determine the scope of the incident and verify that there was no compromise beyond the single stolen API key.
3. As a result of this incident, we:
   1. Clarified and expanded on our security policies applicable to all METR employees and contractors, particularly around putting any METR credentials or data on non-METR infrastructure or devices.
   2. Formalized a security review process for any researchers publicly deploying applications.
   3. Increased our monitoring coverage, and worked to eliminate “noise” alerts.
   4. Added spend alerts to keys where possible.

Incident 2: Attackers probed for internal data

Summary

In early May 2026, METR became the target of a sustained external attack campaign. We were tipped off that we were being targeted by hackers who appeared to be financially motivated and may have been looking to obtain frontier model access. We observed the attackers systematically probing our publicly accessible infrastructure, with heavy use of agents to automate vulnerability discovery, including by credential stuffing authentication providers, attempting OAuth token grants, scanning newly deployed services, and attempting to phish staff.

During the same timeframe, we inadvertently exposed a read-only SQL query mechanism via our public transcript viewer. The queries were scoped to public data by default, but a bug could be exploited to access unpublished evaluation data. This dataset was supposed to contain only data from non-sensitive models, i.e. category 2 above. However, some sensitive model data (i.e. category 3 above) was accidentally included in this database.

We became aware of the issue after an independent security researcher discovered this vulnerability and responsibly disclosed it to us; we took the API offline and paid a bounty.

The attackers had probed this endpoint in passing as part of their broader campaign, but the evidence shows no indication that they discovered the exploit or accessed any non-public data.²

Response

1. After being tipped off, we turned off nearly all public-facing services as well as internal access to sensitive data while we determined the scope of the attack.³
2. We now maintain an isolated public production environment for public-facing applications that is architecturally separated from our internal infrastructure, so that a misconfiguration in a public service cannot expose internal data.
3. We engaged Calif to perform additional red-teaming.

How we’re changing our security process going forward

Above, we summarized changes made based on lessons from specific incidents.

In addition, we have improved our security infrastructure, protocols and review process, including with our ongoing external cybersecurity partner:

• We hired a security lead, and are planning to further expand our security staff, including by hiring a full-time security engineer. We also increased our support from Calif.
• We shut down legacy infrastructure that was unnecessarily expanding our attack surface.
• We are conducting regular threat modeling reviews to flag areas for improvement across our infrastructure.
• We increased our logging coverage across database queries, API usage, and other sources.
• We set up monitoring for unusual API key usage and are setting up other systems to monitor for abnormal behavior.
• We made a variety of other improvements, including deploying additional endpoint and server security software, decreasing longevity of credentials, and reducing various permission scopes.

We will continue to invest in security as our work and the risk landscape evolve.

The measures described above were accurate as of July 30, 2026 and are subject to change.

This post was shared with several of the AI companies we work with ahead of publication, and some minor wording changes were made as a result of feedback.