METR's Vibe-Coded Agent Dashboard Disabled Its Own Login, and an Attacker Spent $600,000 of Model Credit

In March 2026, someone took an API key for METR's public-models account off a researcher's personal Amazon EC2 instance and used it for three weeks. METR — Model Evaluation and Threat Research, the nonprofit that measures how far AI agents get on long-horizon tasks — put the commercial value of the consumed credit at about $600,000. The key was not phished from a human: the attacker prompted an agent running on the researcher's vibe-coded dashboard to hand its model provider API key over, then added an SSH key so it could return. METR disclosed the incident on 31 August 2026, and the record carries the archive's high severity grade and an A confidence rating. The disclosure is one record in the AI incident archive, which holds the full record set, its sources and the neighbouring entries in this series.

What the record actually says

The archive classifies this as a realised incident, not a disclosure of a theoretical weakness: severity high, confidence A, not disputed, with real harm recorded and AI involvement confirmed. The type tag is CRED, the region is the United States, and the date is recorded to the month only — the archive knows the theft happened in March 2026 and does not claim a day, and neither does METR.

The harm needs one qualification, and METR supplies it. The credits were granted to METR free of charge by the model developer, so the $600,000 is the value of what was consumed rather than money that left an account. The Register's standfirst made the same point more bluntly: the model provider gave METR the credits, and an actual paying customer would not have been so lucky. Infosecurity Magazine reported the figure the same way, as commercial value rather than direct financial loss.

METR's post covers two incidents, not one. The May 2026 campaign is described separately further down; the theft of the key and the three weeks of spending are the March event, and they are this article's subject.

The flaw was in the login, not in the model

A METR researcher with no sensitive access ran agents on a personal EC2 instance that had been made publicly reachable on purpose, behind Google authentication. The instance carried an API key for METR's general-access account — the one used for public models, which METR files as its second-least-sensitive data category. The orchestration app around those agents was vibe-coded, and it contained what METR calls a fail-open vulnerability that silently disabled authentication.

Fail-open is worth translating, because it is the whole incident in two words. A login check has two ways to be wrong: it can refuse a legitimate user, or it can admit anyone when the check itself breaks. Fail-open means the second — when the authentication step errored or was skipped, the app treated the request as allowed rather than denied. Nothing alerted. In METR's account the result was a system sitting on the public internet for several days with its front door propped open and no indication that anything had changed.

METR does not name the orchestration tool or the framework the dashboard was built with, does not publish the code, and does not say which way the authentication integration failed. What the post does establish is the architectural mistake underneath the bug: a credential for an organisational model account was present on infrastructure METR did not control, in an application one researcher had deployed themselves.

How the key left the building

METR's reconstruction of the attacker's approach is explicitly a suspicion, not a finding, and it is the most interesting unproven claim in the disclosure. The post says METR suspects the attacker found the instance by browsing recently registered websites — certificate transparency lists are named as an example — looking for vibe-coded sites carrying keywords that signal LLM or agent projects, in order to harvest model provider API keys that had been left exposed.

Certificate transparency logs are public by design: every certificate issued for a publicly trusted site is recorded, so a new hostname appears in a searchable feed within minutes of going live. Filtering that feed for names containing agent or model terminology is cheap, needs no access to the target, and produces a list of fresh deployments that may not have been reviewed by anyone. Read as a hunting technique, it turns the ordinary act of publishing a demo into a signal.

Once inside, the attacker did not need to steal a secret from a filesystem. They prompted the agent directly to reveal its model provider API key, which is a sentence that deserves a moment: the agent had the credential in its context and could be talked into printing it. The attacker then added an SSH key for persistent access, so that closing the authentication hole would not have evicted them, and settled in for three weeks of inference on publicly available models.

The model developer is not named — not by METR, and not by The Register, Dark Reading, Infosecurity Magazine or The Hacker News in their coverage of the disclosure. No CVE was issued, because no product vulnerability is at issue. No arrest, charge or attribution to a named group has been reported.

Why three weeks of abnormal usage looked normal

METR answers the obvious question directly, and the answer is the part other organisations should read twice. The nonprofit runs large-scale evaluations, which means it is thoroughly accustomed to very large token counts and to a stream of odd rate-limit and API errors, many of them spurious. A spike in model traffic was not, by itself, a signal.

Three specific gaps turned that familiarity into three weeks of silence. METR's internal usage dashboard did not show data on rate-limited requests across all users, even when those requests were happening. Because the tokens were free, there was no bill and therefore no natural spending ceiling that would have tripped. And at the time, METR says there was no way to place a spending limit on a key of that kind at all. An organisation paying list price with a hard cap would have hit a wall in hours; an organisation with donated credit and no cap had nothing to hit.

What was not taken

METR's data taxonomy runs from published material up through generic model access, sensitive model access and highly sensitive business information. The researcher involved had no access to the top two categories, and METR states that to the best of its knowledge no data from those categories was accessed as a result of either incident.

Beyond the single key, METR says manual and agent-assisted forensics found no compromise, and that its security consultant, Calif, validated the findings and ran its own compromise assessment. That is a meaningful control — an outside firm checking the account rather than accepting it — but it is not independent of METR, which engaged and paid Calif. No third party has published its own forensic review of the incident.

What METR did when it noticed

The response sequence in the post is concrete. METR worked out that the surge in usage was not part of an evaluation, traced it to the compromised personal instance, revoked all of the researcher's access, stopped and imaged the instance, rotated every credential present on it, and imaged and wiped the researcher's laptop. It alerted the partner AI company whose credits were being spent and kept that company updated through the response.

METR does not explain the reasoning behind the laptop wipe, and it is the one step in the sequence that goes beyond revoking access to the instance itself — the plausible reading is that the same researcher had been handling the credential from a workstation the attacker could reach, and imaging then rebuilding is the cheap way to be sure about a machine.

What changed afterwards

METR lists four changes tied to this incident:

• Security policies for employees and contractors were clarified and expanded, specifically around putting METR credentials or data on infrastructure and devices METR does not own.

• A formal security review process now applies to any researcher who publicly deploys an application.

• Monitoring coverage was increased, with work to eliminate noisy alerts that train responders to ignore them.

• Spend alerts were added to keys where the provider makes that possible — the hedge matters, because the post's earlier point was that some keys of this kind could not be capped at the time.

The disclosure also lists organisation-wide work: hiring a security lead and planning a full-time security engineer, increasing Calif's involvement, shutting down legacy infrastructure that was enlarging the attack surface, running regular threat-modelling reviews, extending logging across database queries and API usage, monitoring for unusual API key usage, deploying additional endpoint and server security software, shortening credential lifetimes and reducing permission scopes. METR dates those measures as accurate to 30 July 2026 and says they are subject to change — a caveat worth keeping, because it means the post describes a state roughly four months after the theft and about a month before publication.

The other incident in the same post

METR's disclosure pairs the key theft with a second, separate event in early May 2026, and the two are easy to blur. In that one, METR was tipped off that it was being targeted by attackers who appeared financially motivated and may have been after frontier model access; it watched them probe its public infrastructure, using agents heavily to automate vulnerability discovery, including credential stuffing against authentication providers, attempted OAuth token grants, scanning of newly deployed services and phishing of staff.

During the same period METR inadvertently exposed a read-only SQL query mechanism through its public transcript viewer. Queries were scoped to public data by default, but a bug could be turned toward unpublished evaluation data, and some sensitive model output had been loaded into that database by mistake. An independent security researcher found the flaw and reported it responsibly; METR took the API offline and paid a bounty. By METR's account the attackers passed the endpoint during their wider campaign but showed no sign of finding the exploit or reaching non-public data — a conclusion METR puts at “highly unlikely” in a footnote rather than at zero.

What is established, and what is not

Established. METR published the disclosure on 31 August 2026 and describes the March theft, the fail-open authentication failure, the agent-mediated key disclosure, the SSH key, the three-week window and the roughly $600,000 valuation. Four security outlets — The Register, Dark Reading, Infosecurity Magazine and The Hacker News — reported the same account within a day, and none of them contradicts it — though all four draw on the same METR post rather than on any independent access to METR's logs or the provider's billing.

Not established. The $600,000 is METR's own estimate of donated credit; no invoice, provider statement or independent valuation has been published, and because nothing was paid, there is no transaction to check it against. The certificate-transparency hunting method is labelled a suspicion by METR and has not been corroborated by any party with visibility into the attacker's activity. The identity of the attacker, the identity of the model provider and the exact day in March are all unknown or unpublished. And the claim that no sensitive data was reached rests on METR's forensics and its consultant's review, not on an external audit.

It is also worth being precise about the word near-miss. METR characterises both incidents that way, and Dark Reading pushed back on the framing for the March event on the grounds that it was a successful compromise in which an attacker established persistence and spent three weeks inside a stolen credential. Both descriptions are accurate about different things: the outcome was contained, and the intrusion was real.

Dark Reading also carried the sharpest outside assessment in its report. Jacob Krell, senior director of secure AI solutions and cybersecurity at Suzu Labs, told the outlet that METR is one of the more security-mature organisations in the AI space, with SOC 2 Type I certification, a dedicated security consultant and a four-tier data classification system, and that the incidents still arrived through ordinary means — a fail-open authentication flaw on a personal cloud instance. If an organisation at that maturity level is caught by basic cloud and credential hygiene, Krell argued, that says something about the floor of AI industry security rather than the ceiling. Dark Reading notes that METR did not respond to its request for comment on the story.

Why an evaluator's key is not a small thing

METR's role is the reason this record sits in a safety archive rather than a cloud-hygiene roundup. Dark Reading reports that the organisation has collaborations with most major Western model vendors, including OpenAI, Anthropic, Google, Meta and Amazon, and The Register notes that METR worked with OpenAI to investigate how OpenAI's agents reached Hugging Face servers earlier in 2026. An evaluator holds unpublicised results, unpublished transcripts and access to models before release; its credentials are, in effect, part of its clients' security perimeter.

The March incident did not reach any of that. It reached a key for public models, on a personal instance, behind a login that had quietly stopped working — which is precisely why it is a useful record. The failure did not require a novel attack on a model. It required a demo deployment nobody reviewed, an authentication check that defaulted to yes when it broke, and an accounting system in which enormous usage was the normal state of the world.