Two breaches at METR, the nonprofit AI lab best known for evaluating frontier models before they ship, show what attackers have learned about the infrastructure behind AI research: it runs on agents that follow instructions, and asking politely can beat an exploit.
METR disclosed both incidents in a security update published August 31, 2026. Neither involved a novel vulnerability class. Both worked because the security boundary around an AI agent turned out to be softer than the boundary around a server.
An agent that answered a question it should not have
In March 2026, a METR researcher deployed an agent orchestration dashboard on a personal EC2 instance behind Google authentication. The application had a fail-open bug: when the authentication check failed, instead of blocking the request, it let the request through. The dashboard sat exposed to the public internet for several days before an attacker, likely scanning certificate transparency logs for newly registered infrastructure, found it.
Media Partner
The attacker did not need to break anything once inside. According to METR, they simply prompted the exposed agent to reveal its own API key, then added SSH access for persistence. Over the following three weeks, they used the stolen credential to consume roughly $600,000 worth of inference on publicly available models, a bill METR was spared only because the model provider had extended those credits for free.
Detection took as long as it did for reasons specific to how AI labs operate. METR runs large-scale evaluations that routinely consume enormous numbers of tokens, so unusual usage did not stand out against a baseline that is already unusual. The internal dashboard tracking spend lacked rate-limit visibility, and the free credits carried no spending cap. A theft that would have tripped an alarm at almost any other kind of company blended into normal traffic at an AI lab.
The second incident: probing the front door
Two months later, METR observed a separate, financially motivated campaign systematically probing its public-facing infrastructure. The attackers automated the reconnaissance with their own agents, credential-stuffing authentication providers, attempting OAuth token grants, scanning newly deployed services as they appeared, and phishing METR staff directly.
During that campaign, the attackers also brushed against a bug in the public transcript viewer, an exposed SQL query endpoint that could have surfaced unpublished evaluation data, including sensitive model outputs. METR says the evidence shows the attackers did not find or exploit that opening. The company still treated it as serious enough to temporarily pull public-facing services offline while it investigated.
“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,” METR wrote in its account of the incident.
What it means for the security leader
The METR case is a useful data point precisely because METR is not a careless organization. It is a lab whose entire mission is finding the ways AI systems can go wrong, and it still shipped a fail-open authentication bug and a public endpoint with more access than intended. That should recalibrate how security leaders think about AI infrastructure risk: the exposure is not hypothetical or confined to frontier-model vendors. Any organization running agent orchestration, evaluation harnesses, or internal AI tooling on internet-facing infrastructure has the same shape of problem.
The more durable lesson is about where the trust boundary actually sits. Treating an agent’s instructions to keep a credential private as a security control, rather than as a behavioral default that a sufficiently direct prompt can override, is the same category of mistake as trusting a user-supplied header. METR’s own fix was not a better prompt. It was rotating credentials, capping spend, separating public infrastructure from internal systems architecturally, and hiring a dedicated security lead. None of that is AI-specific hardening; it is ordinary infrastructure discipline applied to a class of system that had been getting a pass because it is new.
The identity layer is the other gap the incident exposes. An API key that an agent can be talked into disclosing is functionally a shared secret with an unreliable custodian. Security teams evaluating agent deployments should ask whether credentials are scoped tightly enough, and short-lived enough, that a disclosed key is a minor incident rather than a $600,000 one.
The pattern also does not stay confined to research labs. Any enterprise that has wired an internal agent to a code repository, a ticketing system, or a cloud console has created the same disclosure path: a credential the agent holds, and a prompt is all it takes to ask for it. Vendors selling agent platforms mostly rely on the model’s own training to refuse those requests, which is a behavioral guardrail, not an access control. A firewall does not ask an intruder nicely to leave, and a credential store should not depend on an agent choosing to keep a secret.
METR’s response after both incidents went beyond the immediate fix. The lab hired a dedicated security lead, expanded its security staff, formalized threat-modeling reviews for new public deployments, reduced how long credentials stay valid before rotation, and added logging across its databases and APIs. That sequence, detect, contain, then institutionalize the fix, is unremarkable for a mature security program. What makes it notable here is that METR is a research organization that had to build that program reactively, after two incidents in three months, rather than before deploying agent infrastructure publicly. Most organizations moving faster to put agents into production have not done that work at all.
What to do now
Three changes generalize beyond METR’s specific incident. First, treat any internet-facing agent deployment, including ones spun up quickly for internal research, as production infrastructure requiring the same authentication review as a customer-facing service; fail-open bugs hide easily in code written for convenience. Second, put hard spending caps and rate-limit alerting on every API key an agent can access, regardless of whether the credits are free, since usage anomalies are the fastest way to catch a theft that evades other controls. Third, assume any credential an agent can read, it can be talked into revealing, and scope, rotate, and monitor accordingly rather than relying on the model’s own judgment to keep it secret.
Read CyberTech’s related coverage on how AI agents crossed from tool to threat actor in the OpenAI and Hugging Face incident, and on why an AI sandbox is not automatically a safety boundary.
Source: METR
