> ## Content Index
> Fetch the complete content index at: https://www.thecybersignal.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# METR API Key Theft: Attacker Burned $600K in AI Model Credits Undetected for Weeks
- URL: https://www.thecybersignal.com/metr-api-key-theft-600k-ai-credits-3-weeks-2026/
- Published: 2026-09-01T10:39:00.000Z
- Updated: 2026-09-02T06:53:30.000Z
- Description: METR, the nonprofit that stress-tests frontier AI models, says an attacker stole an API key and spent about $600,000 in model credits over three weeks. The provider had donated the credits, so no bill ever flagged the theft.
- Author: Nicholas Robert
- Tags: Artificial Intelligence (AI), Credential Exposure, Cloud Security

METR, the research nonprofit that stress-tests frontier AI models for their ability to carry out long-horizon, agentic work, has disclosed that an attacker stole one of its API keys and quietly spent about $600,000 in model credits over roughly three weeks before anyone at the organization noticed.

The theft cost METR nothing in cash. As the group explained in an [August 31 security update](https://metr.org/blog/2026-08-31-security-update/?ref=thecybersignal.com), the model provider had handed it the credits for free, so no invoice ever landed to trigger an alarm. That single detail is the whole lesson for defenders: a paying customer would have seen the spend on the first billing cycle. METR did not, and the missing bill is exactly why the intrusion ran unchecked for three weeks.

METR (short for Model Evaluation and Threat Research, and pronounced "meter") said it suffered "two notable security incidents" earlier in 2026 in which outside actors tried to reach its systems. It does not believe any sensitive information was accessed in either case, and it said it shared a version of its findings with the AI companies it works with before going public. Neither attack has been tied to a known threat group, and neither involved AI agents breaking into its evaluations.

What this adds beyond the headline number is a reframing: the incident is a clean, expensive proof that a monthly bill is a security control, not just an accounting artifact. Strip the bill away, as free or donated credits do, and one of the most reliable signals of credential abuse disappears with it.

## Why a Missing Bill Is a Security Problem

For most teams, cost is the first thing that flags a stolen cloud or model credential. A crypto-mining bill, a runaway inference tab, a sudden five-figure spike: finance notices, and the security team gets pulled in. That feedback loop is crude, but it works, and it is often the only monitoring a smaller organization has on its API keys.

METR sat in the gap that opens when the loop is switched off. Its key was funded by donated credits from a model provider, so heavy usage produced no bill, no budget alert, and no finance escalation. The attacker was, in effect, spending someone else’s money that no one was counting. Free-tier credits, startup-program grants, research donations, and vendor trials all create the same blind spot: pools of real spend that no invoice is watching. The commercial value was real ($600,000, per METR), but it never converted into the one number that usually catches this behavior early.

## How a Free API Key Became a $600,000 Problem

The costly incident dates to March 2026\. "In March 2026, attackers stole an API key for inference on public models and consumed a substantial amount of credits," METR wrote in its update. The chain that led there is a familiar credential-hygiene failure rather than any exotic tradecraft.

One of METR’s researchers, who had no access to sensitive material (no model data, credentials, architecture details, training information, or release dates), ran agents on a personal Amazon EC2 instance that was intentionally left publicly reachable behind Google authentication. That instance held an API key for METR’s general-access account for public models. A "vibe-coded app" on the box carried a fail-open bug that silently switched authentication off, leaving the agent orchestration dashboard open to the public internet for several days.

From there, per reporting by [The Register](https://www.theregister.com/security/2026/09/01/attacker-stole-a-metr-api-key-used-600k-worth-of-credits-and-no-one-noticed-for-weeks/5293730?ref=thecybersignal.com) and [The Hacker News](https://thehackernews.com/2026/09/attackers-steal-metr-api-key-and.html?ref=thecybersignal.com) summarizing the disclosure, METR suspects the attacker was mining certificate transparency logs for freshly registered sites carrying high-signal keywords about large language models and agents, hunting for exactly this kind of exposed key. Once the dashboard was found, the intruder got the agent to surrender its provider API key, planted an SSH key for persistent access, and spent the next three weeks running up credits on public models. The provider, which METR declined to name, had donated those credits, so the roughly $600,000 tab was never billed.

## Why No One Noticed the Spend

The short answer is that heavy, strange-looking model usage is METR’s normal. Two things kept the theft invisible, and they compounded each other.

First, METR runs large-scale evaluations that burn a high volume of tokens, so its team is, in its own words, "very acclimated to getting lots of weird rate limit and API errors." Illicit traffic blended into a baseline that already looked noisy. Second, because the credits were free, no bill accrued, and at the time there was no way to set a spending limit on the stolen key. The usual tripwire (cost) was disabled by the donation, and the backup tripwire (anomalous volume) was buried under expected noise. Following the incident, METR says it tightened its policies on putting credentials or data on non-METR infrastructure, improved monitoring, hired a security lead, and added spend alerts to keys where it can.

## A Second, Separate Attack in May

The other disclosed incident is unrelated in mechanism. In early May 2026, after being tipped off that financially motivated attackers might be trying to reach frontier models, METR watched a "sustained external attack campaign" probe its public-facing infrastructure. The attackers leaned heavily on agents to automate the work: scanning newly deployed services, credential stuffing against authentication providers, attempting OAuth token grants, and phishing staff.

Around the same time, METR said it had accidentally exposed a read-only SQL query mechanism built into its public transcript viewer. Queries were scoped to public data by default, but a bug could have allowed access to unpublished evaluation data, and some sensitive model data had been mistakenly loaded into that database. An independent security researcher found and reported the flaw, earned a bounty, and METR took the API offline. The group says the evidence shows the attackers probed the endpoint in passing but never discovered the exploit or reached non-public data. In response, it moved public-facing applications into an isolated production environment separated from its internal infrastructure.

## What METR Has Not Confirmed

Several details remain open, and they matter for anyone trying to map this to their own risk. METR has not named the model provider that donated the credits, so the specific platform involved is unknown. It described how the March key was harvested (a fail-open app and an agent coaxed into revealing the key) but has not attributed either incident to a named actor, and the May campaign is characterized only as likely financially motivated. Whether other AI-evaluation nonprofits were swept up in the same activity is unclear from the disclosure. This piece deliberately stops at the exposure pattern rather than the step-by-step tradecraft, because the pattern is the part defenders can act on.

## Who Is Most Exposed to This

This is not only a nonprofit problem. Any organization whose model access is funded by something other than a metered invoice sits in the same blind spot: startups burning through a provider’s free tier or startup-program credits, enterprises running sanctioned proof-of-concept trials, and research teams working on grant-funded or donated allocations. The risk compounds wherever developers self-serve their own keys, because those keys rarely make it into a central inventory, and nobody owns the job of watching what they spend. If the only thing standing between a stolen key and a $600,000 bill is an invoice that never arrives, there is effectively no control at all. The same dynamic quietly powers a lot of shadow AI: a key spun up for a quick experiment, pasted into a side project, and then forgotten while it keeps working.

## What Security Teams Should Do

The defensible version of this story is short: treat every model-provider API key as a spendable credential, and instrument it the way you would a corporate card. The controls below would have converted METR’s silent three-week burn into an alert within hours, whether or not a bill was ever generated.

| ● API Key Hygiene for AI Workloads Five controls that would have turned a silent $600,000 burn into an early alert.                                                           |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Rotate and Revoke on a Schedule Cycle provider API keys regularly, and treat any key that touched a personal laptop or a public app as already burned.                        |
| Scope and Expire Every Key Issue least-privilege, short-lived keys per project. Avoid a single general-access key that can run any public model indefinitely.                 |
| Set Hard Budget and Usage Caps Cap token spend per key, even on free or donated credits. A ceiling turns runaway use into a hard stop instead of a surprise.                  |
| Keep Keys Off Personal and Vibe-Coded Infra No organization credentials on personal cloud instances, laptops, or quickly-built apps that can silently fail open.              |
| Alert on Anomalous Consumption Flag spend spikes, new regions, and new models in near-real-time. Billing silence is not the same as safety: it was the missing tripwire here. |
| Source: METR security update (Aug 31, 2026), and The CyberSignal analysis.                                                                                                    |

*Checklist: five API-key controls for AI workloads, mapped to the failures behind the METR incident. Source: METR security update, Aug 31 2026, and The CyberSignal analysis.*

In practice, that means tagging every model-provider key to a named owner and a specific project, then baselining what normal token volume and spend look like for each one. Treat the provider’s usage dashboard as a monitored log source, not just a page finance checks at month end, and pipe its consumption data into the same alerting that watches the rest of your cloud footprint. A key that suddenly runs at three in the morning, from a new region, against a model the project has never used, should page someone, whether or not a dollar is ever charged.

None of this is exotic. It is the same key-management discipline that belongs in any [AI security program](https://www.thecybersignal.com/ai-security-the-complete-guide/), applied to a category of credential (model-provider keys) that many teams still treat as a developer convenience rather than a funded asset. The same lesson keeps surfacing in recent research: hardcoded or exposed keys in [282 iOS AI apps](https://www.thecybersignal.com/282-ios-ai-apps-api-key-leak-research-2026/), a [hardcoded ClickUp API key](https://www.thecybersignal.com/clickup-hardcoded-api-key-exposed-enterprise-and-government-emails-for-over-a-year-with-no-fix/) that sat exposed for over a year, and a [Gravity SMTP plugin bug](https://www.thecybersignal.com/gravity-smtp-wordpress-plugin-api-key-exposure-2026/) that leaked keys. The pattern is consistent: the key is the crown jewel, and it keeps ending up somewhere it should not be.

**My read:** The free credits did not save METR, they blinded it. Billing is a security signal, and it is one of the few that reliably catches credential abuse in near-real-time. Most organizations would have quietly paid $600,000 for the same silence, because most do not alert on consumption at all until finance flags the invoice. METR got lucky twice here: once that the credits were free, and once that the compromised researcher had no access to sensitive data. Neither is a control. As an assessment rather than a reported fact, I expect model-provider key abuse to become a standard monetization path for credential-theft crews, precisely because free-tier and donated credits create pools of spend that nobody is watching.

## Primary Documents

- [METR, "Security Update"](https://metr.org/blog/2026-08-31-security-update/?ref=thecybersignal.com) (August 31, 2026)
- [The Register: Attacker stole a METR API key, used $600K worth of credits](https://www.theregister.com/security/2026/09/01/attacker-stole-a-metr-api-key-used-600k-worth-of-credits-and-no-one-noticed-for-weeks/5293730?ref=thecybersignal.com)
- [The Hacker News: Attackers Steal METR API Key and Consume AI Credits Worth About $600,000](https://thehackernews.com/2026/09/attackers-steal-metr-api-key-and.html?ref=thecybersignal.com)
- [Infosecurity Magazine: Attackers Steal METR API Key and Burn $600,000 in AI Credits](https://www.infosecurity-magazine.com/news/attackers-steal-metr-api-key/?ref=thecybersignal.com)