A 30-minute emergency checklist after an API key leak

Why the order matters first

Response to a key leak has three actions: disable, investigate, replace.

Get the order wrong and you pay for it:

• Investigate before disabling → the other party keeps burning your quota while you investigate.
• Replace without investigating → the key is changed but the logs were never pulled, so you cannot tell afterwards how large the leak was or how it happened, nor whether other things need hardening.
• Disable without replacing → if the leak path is not closed, the new key leaks the same way.

The correct order: disable, investigate, replace, harden.

The 30-minute checklist

Minutes 0 to 2: disable

Disable the key in the site's dashboard immediately. If it supports temporary disabling rather than deletion, disable it, so the logs remain.

If there is no disable function, delete it.

At the same time: if your code references it through an environment variable, leave that alone for now. The code will error, and that is better than continuing to be charged. Stopping the bleeding comes first.

Minutes 2 to 10: size up the damage

Pull the call log and look at three things:

1. Time range: when the anomalous calls began.
2. Call characteristics: requested models, prompt lengths, call frequency.
3. Source IPs, if the log carries them.

Criteria:

• The call profile is completely unlike yours, with lots of long prompts or high frequency late at night → confirmed abuse.
• Volume spikes sharply in a short window → a scripted drain, typically.
• Only a scattering of extra calls that look like probing → it may just have been scanned, not yet exploited.

Export and save the log. It is your only evidence for recovery or appeal.

Minutes 10 to 15: replace

Generate a new key and update every reference.

Note: do not "keep using the old key for now", and do not "copy it somewhere before deleting".

List every place that references it. This step is the easiest to miss:

[ ] Production environment variables
[ ] Test environment variables
[ ] Local development environment (.env, IDE configuration)
[ ] CI/CD secrets
[ ] Container orchestration secret configuration
[ ] Third-party platforms (monitoring, logging, serverless functions)
[ ] Client tools (Cursor, Cherry Studio, Claude Code config, and so on)
[ ] Scheduled task scripts
[ ] Documents and notes

The last item deserves its own emphasis: keys hard-coded into chat logs, shared documents, README files and code comments are one of the most common sources of leaks.

Minutes 15 to 25: find the leak path

Check in order of frequency:

1. Front-end code: was the key bundled into browser-side JavaScript? If it is visible, it is public.
2. Git commit history: was the key ever committed and then removed? It is still in the history.
3. Public repositories: if it is a public repo, crawlers scan for keys within minutes.
4. Screenshots and screen recordings: the key was exposed during a demo.
5. Third-party tools: some tools upload or sync configuration to the cloud.

The Git history step is the most easily skipped: deleting a file does not delete history. Handling it thoroughly means rewriting history, or, more pragmatically, recognising that this key is already dead, so rewriting history only matters to stop other keys being scanned too.

Minutes 25 to 30: harden

• Set a spending cap on the new key, the last line of defence.
• Add an IP allowlist, if you have a fixed egress IP.
• Move the key out of code into environment variables or a secret manager.
• Add usage alerts, notifying when usage passes twice the baseline.

The three most common leak paths

In order of real-world frequency:

1. Committed to a public repository. Crawlers scan public repos within minutes, and a key can be tried within one or two minutes of the commit.
2. Written into front-end code. Anything visible in a browser is not a secret.
3. Left in documents, chat logs or screenshots. Very common, and often not even recognised as a leak.

Three defences to have in place beforehand, which matter more than the response

One: separate keys

Different keys for different purposes: production, test, local, CI. That confines the blast radius of any single leak to one purpose.

Two: least privilege

• Set a spending cap on every key. This is the most important one, because it is the only measure that stops the bleeding automatically.
• Add an IP allowlist where you have a fixed egress IP.
• If the site supports it, restrict the models a key may use, limiting it to the ones it actually needs.

Three: never in the repo, never in the front end

• Never write a key into code, a commit or a screenshot, under any circumstances.
• Front ends must go through your own backend proxy and must not call model APIs directly.

A realistic reminder

The overwhelming majority of leaked keys were released by their own users, not broken by an attacker. So when discussing key management the focus is not encryption algorithms but process:

• Do you have a habit of putting keys into code?
• Do you check before committing?
• Have you separated keys by purpose?

Do those three and the probability of a leak drops by an order of magnitude. For the rest, the spending cap is your backstop.