METR API key theft shows how stolen credentials can drain AI budgets fast
Published by AINave Editorial • Reviewed by Ramit
AI research nonprofit METR disclosed two security incidents that should concern any builder running token-based AI workloads. In March, attackers stole an API key for METR's public models and consumed $600,000 worth of credits over three weeks without detection. In May, the same attackers probed public infrastructure and attempted to access internal data. METR's account shows how easily a lack of token spend controls and infrastructure segmentation can turn a credential leak into a major financial and security risk.
How the attack unfolded
The first incident started when a METR researcher used a vibe-coded app on a personal EC2 instance that was intentionally made publicly accessible behind Google authentication. The app had a fail-open vulnerability that silently disabled authentication, exposing the system to the public internet for several days. Attackers discovered the instance by scanning recently registered websites for high-signal keywords related to LLMs or agents. They prompted an agent to reveal its model provider API key, added an SSH key for persistent access, and over roughly three weeks used the stolen credentials to consume API credits.
Why the $600k bill went unnoticed for weeks
METR is accustomed to running large-scale evaluations that use large volumes of tokens, so the anomalous usage blended in. The organization had no token spend ceiling on the API key and no way to set spending limits at the time. Its internal usage dashboard did not show data on rate-limited requests to all users, even when they were occurring. As METR explained, the organization wasn't actually paying for the tokens (the model developer provided them for free), so there was no natural financial incentive to monitor usage. A second attack in May involved attackers systematically probing public infrastructure with automated agents, credential stuffing, OAuth token grants, and phishing attempts.
What this means for AI builders
This is a near-miss that could have been much worse for a team paying its own inference bills. The METR case highlights three specific risks for builders: (1) API keys stored in publicly accessible environments can be discovered and abused, (2) large token budgets can hide anomalous usage without monitoring, and (3) public-facing infrastructure that shares access with internal systems creates a lateral movement path for attackers. The incident also shows that attackers are actively using agents to automate vulnerability discovery, including scanning for vibe-coded sites with LLM-related keywords.
Practical steps to protect API keys and token budgets
METR's response provides a useful remediation checklist: isolate public production environments from internal infrastructure architecturally, hire a dedicated security lead, shut down legacy systems, and implement monitoring for unusual API key usage. For builders, the most actionable takeaway is to enforce token spend ceilings or rate limits on every API key, even for internal or experimental workloads. As METR noted, they now maintain an isolated public production environment that is architecturally separated from internal infrastructure, so a misconfiguration in a public service cannot expose internal data. Regularly rotate API keys, review OAuth grants, and use infrastructure-as-code to avoid accidental exposure of credentials.
Important caveats
This analysis is based on a single news article reporting METR's own disclosure. The attacker methods and timelines reflect METR's descriptions rather than independent forensic findings. The fact that METR was not paying for the consumed tokens is unusual; most teams paying for inference would have stronger financial incentives to monitor usage. However, the underlying lessons about API key security, infrastructure segmentation, and monitoring apply broadly to any organization running token-based AI experiments.
