What to do when you leak an API key
Updated October 2026
Revoke the leaked key first. Then make a new one and put it everywhere the old one lived. In that order, every time.
Most people do it backwards. They make the new key, drop it into their code, and forget the old one is still sitting somewhere else, still live. The old key keeps working until someone actually turns it off, and most people never go back to do that. GitGuardian's State of Secrets Sprawl 2025 report checked this across real leaks found on GitHub, and we checked their report October 24, 2026: 70% of the secrets leaked there in 2022 were still valid three years later, in 2025. Nobody revoked them.
Here's the order that actually works.
Step 1: Kill the old key
Go to the provider's dashboard and revoke it. Not "regenerate." Revoke. You want the exact string that leaked to stop working the second you click, before you do anything else. If the provider only offers "regenerate" and doesn't say whether the old key dies immediately, treat it as still live until you've confirmed otherwise. Some providers keep the old key active for a short grace period after you regenerate, which defeats the point if you're in a hurry.
If there's no clean one-click revoke, delete the key entirely and start from zero. A missing key is safer than a key you're not sure about.
Step 2: Check what it touched
Before you move on, look at the provider's usage logs for the hours before you noticed the leak. A spike in requests, traffic from a region you don't operate in, usage that doesn't match your own, a bill that's higher than it should be. That tells you whether someone actually used the key, and roughly what they did with it. Skipping this step means you find out from the invoice instead.
Step 3: Make the new key
Now generate the replacement. Name it something you'll actually recognize in a support ticket six months from now, not "key2" or "prod-final."
Step 4: Put it everywhere the old one was
This is the step people skip, and it's the one that matters most. Grep your codebase for the old key's prefix or a distinctive piece of it. Check your CI secrets, your hosting provider's environment variables, any local .env files on your own machine, and any teammate's machine that might have a copy. One forgotten copy of the old key, sitting in a config file nobody opened in months, is one more place it can keep working from, even after you think you've killed it everywhere that matters. See the rotate hub for the exact places each specific provider stores a key.
If you genuinely can't be sure you've found every copy, that's not a failure of diligence. It's the actual argument for rotating keys on a schedule instead of hunting for every copy by hand after the fact. A key that gets replaced every day is never eight months stale when something goes wrong.
Step 5: Decide if this happens again
If the leak happened because the key sat untouched in a .env file for the better part of a year, the fix isn't just swapping this one key. Nothing was ever rotating it in the first place. Ask the harder question: how did it leak? A key pasted into a public repo, a screen-shared terminal, a dependency that shipped it in a log line. Each of those has a different fix, and "I'll remember to rotate keys more often" is not one of them. Nobody remembers.
This is the whole reason Key Robot exists. It runs from your own GitHub Actions, on a schedule you don't have to think about, and replaces your keys automatically, checking that your app still works before it deletes the old one. If a key leaks between cycles, there's a Kill it now button for exactly this moment, instead of making you run these five steps by hand at 11pm. It's free for one app, no card required, and it never stores your keys itself. They're locked in your browser before they ever leave the page.
We built Kill it now because of a real leak, not a hypothetical one. On October 21, 2026, a stranger used one of the founder's own API keys. Fixing it by hand took two days.
If you want to see every tool that claims to rotate keys for you, not just store them, see the ranked list of API key rotation tools, or compare Key Robot to Doppler directly.
Questions
How fast do I actually need to revoke a leaked API key?
Immediately, before anything else. GitGuardian found that 70% of secrets leaked on GitHub in 2022 were still valid three years later in 2025, which means almost nobody goes back and kills them once the panic passes. A leaked key isn't dangerous because it leaked. It's dangerous because it stays live.
Is regenerating a key the same as revoking it?
Not always. Some providers keep the old key active for a short grace period after you hit regenerate, so a leaked key can keep working for minutes or hours after you think it's dead. Check the specific provider's own documentation for whether regenerate means an instant, hard revoke, or something slower.
What if I don't know everywhere the key is used?
Grep your repository for the key's prefix, then check your CI secrets, your hosting provider's environment variables, and any teammate's local .env files. If you genuinely can't track down every copy, that's the real case for rotating keys automatically on a schedule instead of relying on finding every copy by hand after a leak.