The agent handed over its own API key. $600,000 later, someone noticed.
FIELD REPORT · THE STOLEN KEY · PUBLIC DISCLOSURE · METR · 31 AUG 2026
General notes
- 01An AI evaluation organisation put an agent on a public cloud instance behind a login. The login had a fail-open bug that silently disabled authentication.
- 02The attacker did not hack the key out. They asked the agent for it. Then an SSH key for persistence, and three weeks of inference on someone else's account.
- 03Nobody noticed because heavy usage was normal, the credits were free, and no spend limit existed for that key type. Detection: a usage spike that matched no evaluation.
Schedule of failuresFour boundaries, one instance
| Boundary | What crossed it | The move |
|---|---|---|
| Authentication | A fail-open bug let unauthenticated traffic in | Fail closed. On error, deny |
| The agent | It answered a request for its own credential | Keep secrets outside the prompt boundary |
| Spend | Free credits, no limit, heavy usage looked normal | A cap and an alert are a boundary too |
| Discovery | A new public hostname, found via certificate logs | Assume it is found within hours |
As posted
Last week an AI research organisation published the kind of incident report most companies never write. Someone had stolen one of their API keys and spent about $600,000 of model credits over three weeks before anyone noticed.
The details are worth reading twice, because none of them are exotic.
A researcher put an agent on a public cloud instance behind a login. The login had a fail-open bug: when authentication broke, it let everyone in instead of no one. The attacker found the instance, they suspect, by scanning newly registered websites for names that sounded like AI projects.
Then the attacker did not hack anything. They asked the agent for its API key, and the agent handed it over. An SSH key for persistence, and three weeks of inference on someone else's account.
Why three weeks? Heavy usage was normal there. The credits had been granted free, so no bill arrived. And no spend limit existed for that kind of key. Detection came when someone noticed a usage spike that matched no evaluation.
Four boundaries failed on one instance, and the fix for each is on the sheet. The one I keep coming back to: an agent should never be able to read a secret it does not need. A credential inside the prompt boundary is a credential anyone who can talk to the agent can ask for.
Credit to them for publishing it, in their own words, with the timeline. That is the part worth copying.
Sheet 002.