METR Security Incidents Expose a $600,000 AI Credential Failure

METR disclosed two security incidents after an attacker stole an API key and consumed model credits valued at approximately $600,000. The first attack continued for three weeks, despite generating unusual traffic and repeated rate-limit errors.

The loss did not become a direct bill because the model developer had granted the credits to METR at no charge. That detail limited the financial impact, but it also removed a spending threshold that might have exposed the abuse sooner.

The METR security incidents matter beyond one research organization. An experimental agent dashboard combined cloud access, live credentials, public exposure, and weak monitoring in a single system. That combination turned an authentication failure into prolonged access to valuable computing resources.

METR says its investigation found no evidence that attackers accessed its most sensitive information. However, a second incident exposed how close public research tools came to private evaluation data. Together, the cases challenge the assumption that low-stakes prototypes deserve lighter security controls.

The METR Security Incidents Started With an Exposed Agent Dashboard

The first incident began as a conventional authentication failure, but an AI agent provided the path from public access to credential theft.

In March 2026, a METR researcher deployed agents on a personal Amazon EC2 instance. EC2 is Amazon Web Services’ platform for renting virtual servers. The researcher intentionally made the instance internet-accessible and placed it behind Google authentication.

The application included what METR called a fail-open vulnerability. A fail-open system continues operating when an authentication control fails, instead of denying access. In this case, the failure silently disabled authentication and exposed the dashboard for several days.

The EC2 instance also contained an API key connected to METR’s general-access account for public models. An API key is a credential that software uses to authenticate requests to an online service.

According to METR’s security disclosure, the attacker prompted an agent to reveal that model-provider key. The attacker then installed an SSH key, which created a persistent method for remotely accessing the compromised server.

That sequence is important. The attacker did not need to defeat a frontier model’s safeguards or develop a new AI exploit. The initial opening came from an ordinary web application control that failed in an unsafe state.

The agent still affected the result. Once an outsider reached the interface, the agent could access or reproduce a credential with value outside the application itself. The compromised dashboard therefore became a bridge into a separate model-provider account.

METR suspects the attacker discovered the instance by monitoring recently registered websites. Certificate transparency records can help identify new domains and subdomains because they publicly record issued web certificates.

The organization believes the attacker searched those records for terms related to large language models and agents. Such terms can identify experimental services that might contain valuable provider credentials.

That explanation remains METR’s assessment, rather than a publicly verified attribution. METR has not identified the attacker, the model provider, or the exact discovery infrastructure.

After obtaining the credential, the intruder used it for three weeks. METR calculated that the consumed credits would have been worth about $600,000, although it did not pay that amount.

The incident’s memorable number can distract from the broader failure chain. Public exposure, a credential available to an agent, persistent host access, and incomplete usage visibility all had to remain unresolved.

Any one of those controls could have reduced the damage. Authentication could have denied access. Credential isolation could have prevented disclosure. Host monitoring could have detected the new SSH key. Provider-side limits could have constrained consumption.

The attack succeeded because those defenses did not stop the same sequence.

Why Three Weeks of Model Abuse Looked Like Normal Research

METR’s normal workload created enough operational noise to conceal an attacker’s activity.

METR evaluates advanced AI systems through experiments that can consume large quantities of tokens. Tokens are units used to measure the text processed or generated by a model. Large evaluation runs can also trigger unusual rate limits and provider errors.

That operating pattern weakened a common security signal. High usage did not automatically look malicious because legitimate METR research could produce similar behavior.

METR said its internal dashboard did not show every user’s rate-limited requests when the incident occurred. Investigators therefore lacked a complete view of activity associated with the compromised account.

The organization also had no natural spending ceiling for the affected key. Since the model provider supplied the credits without charging METR, a rising invoice did not force an immediate investigation.

The absence of a bill did not make the resource worthless. Model inference consumes compute capacity, and access to that capacity can be resold or used for unrelated workloads. The attacker obtained a transferable economic benefit even though METR avoided a cash payment.

Independent coverage of the reported timeline emphasized the same monitoring gap. The illicit consumption blended into an environment already accustomed to high token volumes and inconsistent rate-limit messages.

This is the central reversal in the METR security incidents. Scale usually helps a research group test capable models, but that same scale made anomalous consumption harder to distinguish.

Traditional spending alerts can expose a stolen cloud credential quickly. However, donated credits, research allocations, and prepaid capacity can weaken that defense. Organizations still need limits based on usage patterns, request origins, key identity, and expected workloads.

A threshold should also account for failed and rate-limited requests. Those requests can reveal reconnaissance or attempted consumption even when they do not appear in standard billing totals.

The incident shows why raw volume is an incomplete metric. A better detection system asks whether the activity matches the key’s established purpose.

A credential assigned to one experiment should not quietly support unrelated traffic for weeks. Separate keys for each application make that comparison easier because they reduce the number of legitimate behaviors attached to one identity.

Short-lived credentials would further reduce the attack window. A key that expires or requires renewal limits how long a copied value remains useful. Long-lived secrets provide attackers with more time to establish persistence and monetize access.

METR responded by adding spend alerts where providers supported them. It also expanded monitoring coverage and worked to reduce noisy alerts.

Those changes address visible symptoms, but the deeper lesson concerns system boundaries. A research workload should not make unexplained activity acceptable merely because unusual usage happens regularly.

Normal operations need measurable ranges, named owners, and defined exceptions. Otherwise, “research traffic” becomes a broad category that hides both legitimate experimentation and unauthorized consumption.

The Real Conflict Is Fast Experimentation Versus Contained Access

Agent development rewards rapid deployment, while security depends on strict boundaries that prototypes often lack.

METR described the exposed dashboard as vibe-coded, meaning it was developed largely through AI-assisted prompting and iterative generation. That label does not establish that an AI coding tool caused the authentication defect.

The relevant issue is how the resulting application was reviewed and deployed. The software accepted public traffic, interacted with agents, and ran near a live provider credential. Those conditions made it more than a disposable local prototype.

Fast experimentation is valuable in model evaluation. Researchers often need custom interfaces, temporary orchestration tools, and new combinations of models. A long approval process can obstruct exploratory work.

However, the security category should depend on a system’s access and exposure, not its intended lifespan. A temporary application becomes production-like once it is reachable from the internet and holds reusable credentials.

The agent also should not have been able to disclose the raw key. Applications commonly need authorization to call external services, but that does not require placing a reusable secret inside the model’s readable context.

A credential broker can make an authorized request on an agent’s behalf without revealing the underlying key. Narrowly scoped capabilities can also restrict which models, operations, or usage levels the application can access.

This separation matters because language models process untrusted instructions. An attacker who reaches an agent interface can ask the model to expose hidden data, misuse connected tools, or perform actions beyond the application’s intended workflow.

The agent security guidance from OWASP identifies sensitive-data exposure, excessive permissions, tool abuse, and prompt injection as related risks. It recommends limiting privileges and keeping credentials outside agent-accessible context.

The METR disclosure says the attacker directly prompted an agent to reveal its provider key. That resembles prompt-based credential extraction, but the public evidence does not establish the model behavior in enough detail for a formal classification.

The authentication defect was still the first decisive control failure. Without public access, the outsider would not have had an interface through which to issue the request.

Calling the event only a prompt-injection attack would therefore oversimplify it. The loss path combined insecure deployment, secret exposure, permissive agent access, persistence, and weak consumption monitoring.

Likewise, blaming vibe coding alone would miss established security practices that apply regardless of how code was produced. Human-written prototypes can also fail open, expose secrets, and omit telemetry.

METR already had documented security controls for its production evaluation platform. Its published SOC 2 report described controls designed as of August 2025 for that defined system.

A SOC 2 Type I report evaluates control design at a point in time. It does not guarantee that every personal experiment, temporary service, or later deployment follows the same controls.

That distinction sits at the center of the incident. Organizations can secure their principal platform while researchers create parallel infrastructure beyond its formal boundary.

Personal cloud accounts make that fragmentation harder to see. Central security teams may lack logs, inventory, network controls, and automated policy enforcement for instances created outside managed environments.

METR said the researcher lacked access to its two highest sensitivity categories. That limited the apparent blast radius. Yet the instance still contained a provider credential worth targeting.

The lesson is not that experimentation must stop. It is that internet exposure and live credentials should automatically trigger baseline review, even for a short-lived research tool.

A Second Attack Put Evaluation Data at Risk

The May campaign showed that attackers were not interested only in cheap compute; they were also probing paths toward nonpublic model access and evaluation data.

In early May 2026, METR learned that hackers were targeting its public infrastructure. The organization assessed them as financially motivated and said they might have sought access to frontier models.

METR observed systematic probing that included credential stuffing, attempted OAuth grants, scans of newly deployed services, and phishing attempts against staff. Credential stuffing tests previously stolen login combinations against other services.

The organization said attackers made heavy use of agents to automate vulnerability discovery. That claim suggests AI reduced the effort required to scan multiple services and authentication paths, though METR did not publish performance measurements.

During the same period, METR had inadvertently exposed a read-only SQL query mechanism through its public transcript viewer. SQL is a language applications use to retrieve information from structured databases.

The queries were supposed to return public records by default. A bug could alter that scope and expose unpublished evaluation data.

METR expected the underlying database to contain only results involving public models. However, some sensitive model output had been included accidentally.

An independent security researcher found the flaw and reported it responsibly. METR took the affected API offline and paid a bounty.

The attackers had touched the endpoint while scanning METR’s infrastructure. The organization says its evidence shows no indication that they discovered the exploit or accessed nonpublic information.

That conclusion needs careful wording. Absence of evidence does not provide mathematical proof that access never occurred. It reflects what METR and its security consultant found in available logs and forensic material.

METR explained that exploitation required several specific steps. An attacker needed to discover the scoping bug, use it correctly, identify sensitive transcripts, and download them without triggering errors.

The organization considered that sequence highly unlikely. It also acknowledged a complication: it temporarily removed the endpoint, later restored it without noticing the bug, and saw no subsequent attacker access.

This second episode raises different stakes from the stolen credits. Unpublished evaluations can reveal model weaknesses, behavioral patterns, hidden outputs, or information supplied under confidentiality agreements.

METR divides its information into four broad categories. Published material sits at the lowest level. Public-model credentials and unpublished public-model results occupy the next category.

The two higher categories cover sensitive model access and highly sensitive organizational information. METR says its investigation found no access to information in those categories during either incident.

Still, the transcript database contained some material from a higher category when it should not have. That means the intended classification boundary had already failed before anyone attempted to exploit the query mechanism.

Separating data by policy is insufficient if records can enter the wrong database. Effective isolation also needs automated classification checks, access controls at query time, and logs that preserve evidence for later investigation.

The first incident exposed a credential boundary. The second exposed a data boundary. Both involved public-facing research systems sitting closer to valuable resources than their intended roles justified.

METR’s Response Reduces Risk but Leaves Verification Questions

METR has changed its architecture and security process, but outsiders cannot yet measure how consistently those controls cover future experiments.

After detecting the March abuse, METR revoked the researcher’s access and stopped the compromised instance. It created a forensic image, rotated credentials, imaged and wiped the researcher’s laptop, and informed the relevant model company.

Security consultancy Calif reviewed METR’s findings and performed a separate compromise assessment. METR also used manual and agent-assisted forensics to investigate the incident.

The organization says those efforts found no compromise beyond the single public-model API key. It has not published the consultant’s complete assessment, detailed indicators of compromise, or the identity of the provider.

METR expanded policies covering credentials and data on personal infrastructure. It also created a formal security review for researchers who deploy public applications.

Following the May campaign, METR temporarily disabled nearly all public-facing services and internal access to sensitive data. It then created an isolated public production environment separated architecturally from internal infrastructure.

That separation directly addresses the transcript-viewer risk. If enforced consistently, a defect in a public application should no longer provide a route into an internal data system.

METR also shut down legacy infrastructure, increased logging, shortened credential lifetimes, reduced permission scopes, and deployed more endpoint and server security software.

The organization hired a security lead and said it planned to expand the team further. It also commissioned additional red-team work, where authorized testers simulate attacker behavior to find weaknesses.

These steps align with the failure modes disclosed. They improve inventory, containment, credential handling, telemetry, and accountability.

The skeptical question concerns coverage. Policies and centralized environments only work when researchers cannot bypass them through personal cloud accounts, unmanaged services, or credentials copied into experimental tools.

METR has not published measurable targets for that coverage. Readers do not know what percentage of public deployments now receive review or how quickly abnormal key use generates an investigation.

It also remains unclear which controls operate at the model-provider layer. Spend alerts help, but hard usage caps, short-lived tokens, narrower scopes, and automatic revocation offer stronger limits.

Not every model provider exposes the same controls. METR noted that it could not place a spending limit on the affected key when the March incident occurred.

The provider therefore shares part of the wider design problem, even if METR controlled the exposed application. Organizations handling valuable model access need account features that assume keys will eventually leak.

The disclosure itself deserves recognition. METR published a detailed sequence, acknowledged multiple internal failures, and distinguished possible exposure from evidence of actual access.

However, transparency should not be confused with independent verification. The central findings still come from METR’s investigation and its retained consultant.

No public evidence identifies the attackers or confirms their motives. The $600,000 valuation also represents the approximate value of granted credits, not a paid invoice or independently audited loss.

Those qualifications do not erase the incident. They define what the available evidence supports and prevent the headline figure from becoming more precise than the facts.

What Security Teams Should Watch After the METR Disclosure

The next test is whether METR’s new controls produce visible limits, faster detection, and safer public research systems.

The first signal is enforcement around public deployments. METR has formalized security reviews, but the value of that policy depends on whether every internet-facing experiment enters a managed inventory.

A useful result would include automated discovery of new domains, cloud instances, and public endpoints associated with the organization. Security teams should compare that inventory with approved applications and named owners.

If future research tools consistently run inside the isolated public environment, METR’s response will support its claim that architectural boundaries have improved. Another personal deployment containing live credentials would weaken that conclusion.

The second signal is measurable credential containment. METR added usage monitoring and spend alerts where possible, but alerts still require interpretation and response.

Organizations should look for shorter credential lifetimes, application-specific keys, narrow provider permissions, and automatic suspension after abnormal activity. Raw credentials should remain inaccessible to an agent’s prompt context and output channel.

OWASP’s discussion of prompt injection risks explains why model instructions alone cannot protect a secret. An attacker can manipulate an exposed model into ignoring intended restrictions or revealing information available within its context.

If METR or its providers adopt brokered access and hard consumption limits, a similar interface compromise should produce a smaller loss. If controls remain primarily alert-based, attackers may still operate until a person recognizes the pattern.

The third signal is evidence about data separation. METR says its new public environment is architecturally isolated, but the May issue also involved sensitive records placed in the wrong database.

Network isolation will not correct misclassified information by itself. METR needs safeguards that detect restricted evaluation data before it enters public-facing storage.

Future disclosures, audits, or technical updates should show whether those controls prevent both direct access and accidental data placement. A clean external assessment would strengthen confidence in the revised boundary.

The METR security incidents also give AI companies a reason to revisit how they provide evaluation access. External evaluators need realistic model capabilities, but broad, long-lived credentials create attractive targets.

Providers can reduce that risk through scoped tokens, per-project limits, origin restrictions, rapid revocation, and visibility into rejected requests. Those features protect both the provider and the evaluator.

Developers should apply the same reasoning to smaller agent projects. A prototype that can reach email, source code, cloud services, or internal documents already has a meaningful security boundary.

Teams documenting such experiments can use a controlled knowledge base to preserve threat models, deployment owners, review decisions, and incident lessons. Documentation cannot replace technical controls, but it can make unmanaged exceptions easier to find.

The most useful question is not whether an application was vibe-coded. It is whether an untrusted user can reach it, what credentials it can access, and what happens when every instruction is treated as hostile.

METR’s disclosure provides a rare, concrete answer. A public authentication failure reached an agent, the agent exposed a credential, and incomplete monitoring allowed three weeks of unauthorized use.

Security leaders should now test that same chain inside their own systems. Can an outsider discover the interface? Can the model reveal a secret? Can the host accept persistent access? Can abnormal consumption blend into expected traffic?

If any answer is yes, the absence of a current incident reflects timing rather than containment. The next METR update should show whether its new architecture has converted hard-earned lessons into enforceable limits.