Full Report
The model provider gave METR the credits for free. An actual customer would not have been so lucky
Analysis Summary
# Incident Report: METR API Key Theft and Infrastructure Probing
## Executive Summary
In March 2026, an attacker exploited a "fail-open" authentication bug on a researcher's public EC2 instance, stealing an API key for public AI models. The attacker spent approximately $600,000 in credits over three weeks without detection, as the high usage blended with normal research activity. A second, separate campaign in May 2026 involved systematic probing and the discovery of an inadvertently exposed SQL endpoint, though no sensitive data exfiltration was confirmed in either event.
## Incident Details
- **Discovery Date:** Approximately late March/early April 2026 (Incident 1); May 2026 (Incident 2)
- **Incident Date:** March 2026 and May 2026
- **Affected Organization:** METR (Model Evaluation and Threat Research)
- **Sector:** AI Research / Nonprofit
- **Geography:** United States / Global (Cloud-based)
## Timeline of Events
### Initial Access (March 2026)
- **Date/Time:** March 2026
- **Vector:** Exploitation of a "vibe-coded" application with a fail-open authentication bug.
- **Details:** An EC2 instance used by a researcher was left publicly accessible. A bug disabled Google authentication, allowing attackers to find the site via Certificate Transparency lists.
### Lateral Movement / Persistence
- **Persistence:** The attacker added a custom SSH key to the compromised EC2 instance to maintain access after the initial entry.
- **Credential Theft:** The attacker prompted an AI agent running on the instance to reveal the organization's model provider API key.
### Data Exfiltration/Impact
- **Usage Impact:** The attacker consumed roughly $600,000 worth of public-model API credits over a three-week period.
- **Data Impact:** No evidence was found that sensitive model architectures, training data, or internal credentials were compromised.
### Detection & Response
- **Discovery:** The $600k usage went unnoticed for weeks due to high baseline research usage and a lack of billing alerts (credits were free).
- **Response Actions:** Improved security infrastructure; hired a dedicated Security Lead; isolated production environments from internal infrastructure.
## Attack Methodology
- **Initial Access:** Exploitation of misconfigured/buggy web authentication (fail-open).
- **Persistence:** Authorized SSH key injection.
- **Privilege Escalation:** Not applicable (direct access to API key).
- **Defense Evasion:** Blending malicious API traffic with legitimate, high-volume research traffic.
- **Credential Access:** Prompt injection/manipulation of an AI agent to leak API keys.
- **Discovery:** Scanning Certificate Transparency lists for high-signal keywords (LLM, agents).
- **Lateral Movement:** Not reported.
- **Collection:** Automated usage of API credits.
- **Impact:** Resource exhaustion (financial/credit consumption).
## Impact Assessment
- **Financial:** $600,000 in model credits consumed (Loss absorbed by the provider as credits were donated).
- **Data Breach:** Exposure of a read-only SQL query mechanism (May incident); however, no non-public data was confirmed stolen.
- **Operational:** Redesign of production environment architecture.
- **Reputational:** Public disclosure of security "snafus" regarding AI safety research.
## Indicators of Compromise
- **Network indicators:** Traffic to/from unauthorized EC2 instances; high-volume API calls to model providers.
- **File indicators:** Unauthorized SSH `authorized_keys` entries.
- **Behavioral indicators:** Unusual prompts to agents requesting system environment variables or API keys; systematic probing of public endpoints.
## Response Actions
- **Containment:** Revocation of compromised API keys; taking exposed SQL endpoints offline.
- **Eradication:** Removal of unauthorized SSH keys; patching the "fail-open" authentication bug.
- **Recovery:** Migration of public-facing applications to an isolated production environment.
## Lessons Learned
- **Baseline Anomalies:** High-volume research environments make it difficult to distinguish "malicious high usage" from "normal high usage" without granular monitoring.
- **Vendor Limitations:** The lack of spending limits or "kill switches" on API keys prevented early mitigation.
- **Shadow IT/Research Risks:** Researcher-led "vibe-coded" apps lacked the rigorous security reviews applied to core infrastructure.
## Recommendations
- **Implement Usage Quotas:** Set hard limits on API key expenditures, regardless of whether credits are free or paid.
- **Network Segmentation:** Ensure research/testing environments are strictly isolated from production environments and sensitive data.
- **Automated Scanning:** Monitor Certificate Transparency logs for the organization's own domains to identify rogue or forgotten public-facing endpoints.
- **Agent Guardrails:** Program AI agents to never reveal environment variables or credentials through prompt interfaces.