Rotating a Leaked AI Key Is Too Late. Cap It Before It Leaks.

You get a spend alert at midnight. By the time you've found the key and revoked it, the bill already has a comma in it.

That was a few developers' weekend after OpenCode's breach. I don't use OpenCode Console, but when I sat down that Sunday to check my own setup, I couldn't name every place my AI keys lived.

Rotating a key fixes the leak you know about. A hard spend cap limits the one you don't, however it happens. And in the last two weeks it happened three different ways.

Here's how each leak worked, where each provider now lets you put a ceiling on a key, and the setting I'd change first in Anthropic's console.

Three leaks, three different doors

A hosted gateway. OpenCode Console stores the provider keys a team links to it, so members can use the models without ever seeing the key. Over the weekend of 17–18 October, OpenCode said an intruder had reached a legacy system it was retiring, affecting 1.4% of Console users who had OpenAI, Anthropic or Google linked (TechCrunch, StepSecurity).

Developers posted unauthorised charges in the hundreds of dollars, a few above $1,000. One Reddit user put theirs at $400 on Anthropic (Notebookcheck). The open-source CLI wasn't affected; as co-founder Dax Raad put it, "those keys never come to us."

Your own laptop. On 15 October, Symantec reported that new builds of the Aoki infostealer now collect AI coding tool credentials: Claude's .claude.json, Codex's config and .env files, and tokens for Copilot, Cursor, Gemini and others (Infosecurity Magazine, SC World). Earlier versions went after browsers and crypto wallets. AI credentials have joined that list.

A package you trust. On 21 October, litellm 1.107.0 went out on PyPI and in the official Docker images with a credential stealer in every wheel. It ran whenever Python started, whether or not anything imported litellm, and collected cloud credentials, .env files and AI tool tokens (StepSecurity). It was live for about two hours, and it's the second LiteLLM compromise this year (Datadog Security Labs). LiteLLM is a proxy that sits in front of several model providers, so a machine running it often holds every key a team has.

Three different doors, and the same thing walked out of each: a credential that bills whoever owns it.

The bill is what they were after

An AI provider key is a bearer credential. Whoever holds a copy can run paid requests on your account until it's revoked. Symantec described Aoki's motive the same way: stolen tokens let an attacker work under your identity and spend your quota.

Every write-up of these incidents ends with the same advice: revoke and rotate. That's right, and it's also after the fact. Rotation needs you to notice first, and the tools for noticing are slower than the attacker:

• On OpenAI, a spend alert sends a notification and doesn't stop traffic (OpenAI help).
• Google says AI Studio's billing data can lag by around ten minutes, so usage can run past a project cap before it registers (Gemini API billing docs).

This time the providers stepped in. Anthropic and Google blocked the OpenCode keys they believed were affected, and OpenAI refunded its API customers. I wouldn't plan around that. The next leak might come from a smaller tool nobody is watching, on a Friday night.

When I did my own count, I found 7 keys in 5 places: .env files in client repos, a CI secret, an automation tool I tried once in the spring and forgot, and a note in my password manager. Only my main key had an alert on it. None had a hard ceiling.

Where each provider lets you set a ceiling

All three big providers now let you cap spend per project, and each has a catch.

OpenAI. Set a monthly spend limit for the organisation or for a single project, then turn on "Enforce a hard limit". Once spend reaches it, requests fail with a 429 until the month resets or you raise it. A project limit covers only that project's traffic; the organisation limit covers everything (OpenAI docs). The catch: the hard limit is off until you turn it on.

Google (Gemini API). Since March, each project in AI Studio has a Spend tab with a monthly spend cap (Google). Your billing tier also carries a system cap; Tier 1 is $250 a month. The catch is the ten-minute billing lag: treat the project cap as a ceiling with some overhang, not an exact stop.

Anthropic. In the Claude Console, each workspace has a Limits tab where you can set a monthly spend limit lower than your organisation's, plus email notifications at amounts you choose (Anthropic support). The catch, from Anthropic's own docs: you can't set limits on the Default workspace (Claude docs). A key there is bounded only by your organisation-wide limit.

That last line was my problem. 4 of my keys sat in the Default workspace, because that's where the Console puts you on day one and I never moved. I made one workspace per project, gave each its own cap, created new keys inside them and revoked the old ones.

What changed in my client work

I maintain 6 client apps that call an AI API: product descriptions for a clothing store's admin panel, a support assistant on a restaurant ordering site. Until this month most of them ran on keys under my account, and I billed the usage back each month. If one of those keys leaked, the bill was mine first and the conversation with the client second.

Now each client gets its own project or workspace, a hard monthly cap of $100, an alert at half that, and a key that lives only in that client's server environment. For new work, I ask the client to open the provider account in their own name and add me as a developer. The card on file and the ceiling are then theirs to decide, and the cap becomes a line in the quote instead of an afterthought.

In my view, a hosted dashboard that keeps your keys is a reasonable product for a team. For a solo freelancer it's one more place a key can leak from, and I'd rather not add one.

Check your own machine

These take a few minutes. Run them on your own machine only.

Find AI keys sitting in plain text in your projects (adjust ~/code to wherever you keep repos):

grep -rElI "sk-ant-|sk-proj-|AIza" ~/code --include=".env*"

grep -rElI "sk-ant-|sk-proj-|AIza" ~/code --include=".env*"

You get a list of files. Each one holds a key worth moving into a capped project, then rotating.

See which AI tool credential files exist, the kind Aoki looks for:

ls -la ~/.claude.json ~/.codex/config.toml ~/.codex/auth.json 2>/dev/null

ls -la ~/.claude.json ~/.codex/config.toml ~/.codex/auth.json 2>/dev/null

Any file listed is a credential to protect. If your machine is ever infected, rotate everything these tools can reach, not just the API key.

Check you never installed the bad LiteLLM release:

pip show litellm 2>/dev/null | grep Version

pip show litellm 2>/dev/null | grep Version

Anything except Version: 1.107.0 is fine. If you see 1.107.0, or you ran a LiteLLM container pulled on 21 October, StepSecurity's advice is to treat that machine as fully compromised.

What I'd do

Put a hard cap behind every AI key you own today, before you decide anything else about where keys should live. My usual spend across all keys is about $180 a month; I'd rather a feature stop for a day than find out I paid for someone else's training run.

The exception is a production feature where a cap firing would break a client's checkout. There I set the cap well above normal peak and the alert just above normal, so I hear about trouble before the ceiling does. The whole clean-up took me 35 minutes.

Each week I test one AI coding claim against real client code. Follow if you want the next one.

Where does your oldest AI key live right now, and does it have a ceiling?