Dormant AI API Keys: Revoke What Your Retired Servers Still Hold
Why a retired key is still a live credential
An API key outlives the infrastructure it was issued for. Retiring a server, closing a project or shutting down an account does not revoke the credentials that belonged to it, because revocation is a separate action that only happens if the decommission plan names it and somebody owns it. That is what makes the exposure silent: nothing you still run breaks when a retired key is used, and the usage itself can be delayed by months, so the environment everyone stopped watching is exactly the one nobody is monitoring. When it finally shows up, the invoice is often the only reliable detector you get — a billing alert, or a charge on an account where you expected to spend nothing.
This page is the checklist for that gap, and it is deliberately narrow. Our main write-up of LLMjacking and AI API key theft covers how keys get stolen and how to respond when the spend is immediate; the AI agent decommissioning checklist covers agent identities that outlive their pilot. This one covers API keys attached to infrastructure you have already retired.
A key that outlived its servers
On 13 September 2026 at 17:59 UTC (13:59 ET), the developer known as @levelsio described the pattern in his own words. He had killed his OpenClaw VPS servers months earlier, and that day he got a billing alert on a separate Claude account, claudeforopenclaw@. He checked his terminals and his VPS sessions and confirmed that none of them used the API, and he then closed the account. His post carries two details that matter for the checklist below: the account was deliberately kept on its own separate one, and it did not have auto reload on.
The chain that connects those events is his stated guess rather than a finding, and he is explicit about that: “I guess at some point it got hacked and the Claude key inside OpenClaw got exposed and then they waited for months before using it on Fable 5.1.” No vendor has disclosed an intrusion in this case and no forensic account of the path has been published, so read the months of dormancy as his inference, not as a confirmed intrusion chain. The dated facts are the billing alert, the retired servers, the silent exposure and the fact that a billing alert was the only notice he got.
Anthropic's September 2026 report, Countering misuse of AI, is the direction-of-travel citation here rather than a description of this case. It is dated 10 September 2026, it runs 154 pages, and it covers activity the company disrupted between December 2025 and August 2026. Its own words are the ones worth carrying into a budget conversation: “Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials—because attackers treat them with the same level of seriousness, too,” and “AI access should be purchased only through authorized channels.” Its supply-chain finding is the one that lands on this page: access to AI in the form of “compromised API keys, session tokens, and devices has increasingly become the sole objective of multiple criminal groups,” groups that sell that access through brokers whose reseller networks “rotate in new stolen API keys and session tokens until they exhaust their usage.” That is deliberate key theft, actively rotated and spent — and it is a reason to treat credentials on retired infrastructure as inventory rather than history. One caveat in the other direction: the report documents no dormant, retired or unused keys, so do not read the months-long lag in the case above as an Anthropic finding.
What nobody has published about stolen keys
No reliable figure has been published for how many AI API keys are stolen, or for what share of them sit dormant before they are used. This page prints none, and it does not estimate one. The counts that circulate publicly measure other things — credentials recaptured across every service type, or credential sharing inside enterprises — so none of them answers this question, and a number quoted at you as the rate of AI key theft is measuring something else.
Dormant AI API key checklist: seven actions for this week
Every item is one action with a visible finish line, and none of them needs a security tool you do not already have.
- Build one key inventory for each environment you own, and include the cloud accounts, projects and environments you have already retired rather than only the live ones.
- Map every key on that inventory to the service that still uses it and the person who still answers for it, so anything with no live service and no live owner is visibly unowned instead of quietly forgotten.
- Revoke every key that belongs to a retired server, a closed project or an account you no longer use, and record the date it was revoked, because an unrecorded revocation is indistinguishable from one that never happened.
- Add credential revocation to the decommission step itself, so that shutting down a server, project or account does not close until its keys are gone, the same way it does not close until its DNS records are handled.
- Set a billing alert on every retired environment and hold expected spend there at zero, which turns any charge into an incident to investigate rather than a variance to explain away.
- Keep high-risk AI accounts financially isolated, with auto-recharge switched off, so a leaked key in one of them can spend down a prepaid balance but cannot refill it on its own.
- Re-audit the key inventory after a vendor breach disclosure or an employee offboarding, because both events move credentials between hands faster than any annual review does.
Where to start this week
Start with the environments you have already shut down, because those are the ones where no remaining reason exists for a key to be live and nobody is left watching the spend. The theft-and-response playbook for keys that are still in use — leaked credentials, immediate spend, attacker-created identities — sits in our main write-up: LLMjacking: how leaked cloud keys let attackers burn your AI budget. Anthropic's own framing is the reason this is worth an afternoon, because it asks you to hold an AI key to the standard of a production credential; the seven actions above are what that standard looks like once a server is gone.
Frequently asked questions
Do API keys stop working when you retire the server or project they were issued to?
No. A key is a credential rather than a property of the server, so shutting the infrastructure down does not revoke it; revocation is a separate action with its own owner and its own date, and until someone performs it the key keeps working wherever it was copied.
What does an unexpected AI API charge on an account you have retired mean?
Treat it as the strongest signal you are going to get, because expected spend on a retired environment is nothing. That is the signal that surfaced the case on this page on 13 September 2026: a billing alert on a Claude account whose servers had been switched off months earlier.
Is there a published figure for how many AI API keys are stolen?
No. No reliable figure has been published for the number of stolen AI API keys or for the share of them that sit dormant before use, so this page prints none and estimates none. The counts that circulate publicly measure other things, such as credentials recaptured across every service type, or credential sharing inside enterprises.
Sources: @levelsio on X, 13 September 2026, 17:59 UTC (the case above; twiscan mirror) · Anthropic, “Countering misuse of AI: September 2026,” published 10 September 2026 — cited for direction of travel; its length and activity window were measured from the published PDF.