A vibe-coded app exposed METR's API key and consumed $600,000 in free credits

METR, an independent AI evaluator, disclosed that a March breach exposed an API key on a researcher's personal Amazon Web Services instance, allowing attackers to consume approximately $600,000 in free model credits provided by an unnamed developer. Founder and CEO Elizabeth Barnes said the key was left publicly reachable for several days due to a fail-open authentication flaw in a 'vibe-coded' agent dashboard, and METR believes attackers did not access sensitive model outputs.

A vibe-coded app exposed METR's API key and consumed $600,000 in free credits The AI evaluator says a March breach exposed an API key, while a May campaign probed an endpoint that could theoretically expose sensitive model outputs. METR believes attackers did not access that data. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: METR https://metr.org/blog/2026-08-31-security-update/ Why it matters Independent AI evaluators need privileged model access to remain useful. METR's near-misses show that ordinary deployment shortcuts can threaten the trust supporting that access. Elizabeth "Beth" Barnes @bethmaybarnes https://x.com/bethmaybarnes?ref=runtimewire , the founder and CEO of METR https://metr.org/?ref=runtimewire , disclosed in an August 31 security update https://metr.org/blog/2026-08-31-security-update/?ref=runtimewire that external attackers exploited weaknesses around the AI evaluator's public infrastructure in two incidents earlier this year. One stolen API key was used to consume model credits with a list value of approximately $600,000. The credits had been provided free by an unnamed model developer, so METR did not absorb a $600,000 bill. The March compromise still exposed a costly control failure: a researcher placed the key on a personal Amazon Web Services instance running a "vibe-coded" agent dashboard whose authentication failed open, leaving it publicly reachable for several days. Barnes built METR to provide independent scrutiny of advanced AI systems, a mission that requires privileged access to unreleased models, hidden chain-of-thought outputs and confidential information from major laboratories. Her METR biography https://metr.org/team/beth-barnes/?ref=runtimewire says she previously worked on forecasting deep-learning progress with DeepMind's chief scientist and later handled safety targets, scalable oversight and pre-release evaluations at OpenAI. METR began as ARC Evals in 2022 before becoming an independent nonprofit. That background makes METR's security disclosure https://metr.org/blog/2026-08-31-security-update/?ref=runtimewire consequential beyond the lost credits. Barnes has spent four years building a neutral evaluator that frontier laboratories can trust with information they will not publish. METR's near-misses show how quickly that trust can be exposed by an experimental deployment outside the organization's managed infrastructure. A $600,000 blind spot METR said the March incident began when a researcher without access to sensitive models or confidential data deployed an agent-orchestration application on a personal EC2 instance. The instance was intentionally internet-facing and placed behind Google authentication, but the application's fail-open flaw silently disabled that protection. METR suspects an attacker found the application by monitoring newly registered websites or certificate-transparency records for terms associated with language models and AI agents. After reaching the dashboard, the attacker prompted an agent to reveal the model provider's API key, installed an SSH key to preserve access and used the stolen credential for roughly three weeks. The attack worked because several individually understandable decisions lined up badly. A researcher wanted to deploy an experiment quickly. The application carried a general-access key rather than credentials for private models. The tokens were free, removing the natural warning supplied by a rising cloud bill. METR also said its internal dashboard did not display all rate-limited requests to users, while unusually heavy usage and provider errors were routine during large evaluation runs. METR eventually traced the traffic to the personal instance, revoked the researcher's access, imaged and stopped the server, rotated credentials, and wiped the researcher's laptop. Security consultancy Calif https://calif.io/?ref=runtimewire reviewed the incident and conducted a separate compromise assessment. METR said its forensic work found no compromise beyond the public-model API key. The remediation was aimed squarely at the gap between research autonomy and institutional controls. METR formalized security reviews for public applications, restricted the use of its credentials and data on personal infrastructure, expanded usage monitoring and added spending alerts where providers support them. Attackers found a second opening The March theft was followed by a sustained probing campaign in early May. METR observed attackers using agents to automate vulnerability discovery, stuff credentials into authentication services, attempt OAuth grants, scan newly deployed services and target staff with phishing. During that period, METR had inadvertently exposed a read-only SQL query mechanism through its public transcript viewer. Queries were supposed to be limited to public information, but a bug could have allowed access to unpublished evaluation data. Some sensitive model outputs had also been placed in the database by mistake. An independent security researcher found the vulnerability and reported it to METR, which removed the API and paid a bounty. METR said the attackers touched the endpoint while scanning its infrastructure, but its evidence showed no indication that they discovered the exploit or retrieved nonpublic information. That conclusion remains METR's assessment rather than an independently published forensic finding. The August 31 account does not identify the attackers, name the provider whose key was stolen or describe the sensitive transcripts that were theoretically exposed. METR said several AI companies reviewed the post before publication and suggested minor wording changes. METR responded by moving public-facing applications into an isolated production environment separated from internal infrastructure. It also shut down legacy services, broadened database and API logging, shortened credential lifetimes, reduced permission scopes, added a security lead and began recruiting a full-time security engineer. The disclosed measures were current as of July 30. The evaluator's own control problem METR has previously described centralized identity management, network isolation, least-privilege access and cross-platform monitoring as core elements of its security program https://metr.org/blog/2026-02-17-how-we-protect-confidential-information/?ref=runtimewire . It also holds a SOC 2 Type I certification. The incidents show the boundary of those controls: managed systems can be hardened while a single personal deployment recreates an exposed path around them. The risk grows with METR's technical reach. Its open-source Hawk evaluation platform https://hawk.metr.org/?ref=runtimewire provisions cloud infrastructure, routes calls to multiple model providers, manages credentials and stores evaluation transcripts. METR also works with OpenAI, Anthropic, Google DeepMind, Meta and Amazon on model evaluations and risk assessments. Each new integration creates useful research capacity and another set of credentials, services and data flows that must remain compartmentalized. METR also has new funding commitments to address that problem. It said in an August 14 funding update https://metr.org/blog/2026-08-14-funding-update/?ref=runtimewire that it secured approximately $71 million in commitments over the preceding six months from philanthropic supporters including The Audacious Project, the Sijbrandij Foundation, Pew Charitable Trusts, Schmidt Sciences and the Packard Foundation. METR says it does not accept funding from frontier AI companies, although those laboratories provide free tokens and model access. The disclosure also clears up a potential source of confusion around METR's evaluation work. METR said these were attacks by outside actors against its systems and that an initial scan found no evidence of AI agents hacking third parties during its evaluations. That distinction matters after RuntimeWire reported in August that METR documented large groups of agents coordinating during a simulated attack involving Hugging Face /article/openai-s-safeguards-missed-1-200-agents-coordinating-before-700-hacked-hugging-f . METR's decision to publish the incidents gives other research organizations a useful account of how AI infrastructure is being hunted in practice. Attackers did not need an exotic model exploit. They found an authentication failure, asked an agent for its secret and benefited from monitoring calibrated to treat enormous token usage as ordinary. Barnes' challenge is to preserve the experimental speed that made METR influential while making personal deployments, free credits and public research tools obey the same security boundaries as its most sensitive evaluations.