Every leaked API key triggers the same instinct: delete the line of code, commit the fix, move on. That instinct is wrong twice over. The key still works — deleting it from code does nothing to the credential itself — and the copy in git history is permanent until you rewrite it. Here is the sequence that actually contains the damage.
Step 1: Assume compromise
Until proven otherwise, treat the leak as already-exploited. Scanners watch public repositories and paste sites continuously, and a key exposed for even minutes may have been tested. This assumption changes your response from "cleanup" to "incident": it means auditing, not just deleting.
Step 2: Revoke the key first
Before editing a single file, kill the credential at its source. In the provider console or API, revoke or rotate the key. This is the only step that stops an attacker from using it — everything else is hygiene. If the key has siblings (the same credential copied into staging, another repo, a teammate's machine), revoke those too. And check the provider's audit log while you're there: it tells you when the key was used, from where, and on what.
Step 3: Map the blast radius
Revocation stops the bleeding; the audit answers "what did they reach before I stopped them?" Check the key's permissions — was it read-only on a sandbox, or admin on production? Then pull the provider's activity logs and correlate with the exposure window. If the key touched customer data, this is where legal and disclosure obligations enter. For a practical way to think about scope, see our guide to blast radius.
Step 4: Purge it from code — and history
Now the cleanup. Remove the key from the working tree, then rewrite git history so the credential is gone from every commit, branch, and tag — a fix on HEAD leaves the key readable in a 2023 commit forever. Full instructions in our guide to committing a secret to git and the git-history purge walkthrough. Finally, rotate anything the leaked key could access: database passwords, deploy tokens, signing keys. Assume it all leaked together.
Step 5: Monitor and verify
For the next days, watch the affected services closely: unexpected API activity, new resources, login anomalies. Verify the purge worked by scanning your own history the way an attacker would — if a fresh scan finds the key, so will they.
Step 6: Prevent the next one
The post-incident question is always the same: how did this reach production? Usually it's one of three gaps — nothing scanned before commit, nothing blocked at push, or nobody was watching the sources beyond git. The fix is layered: a pre-commit scan that catches the key before it lands, push protection that blocks it if it slips through, and continuous scanning of history and non-code sources. One tool covering all three beats three tools that each cover one. Vooda does exactly that — 900+ rules, AI triage to keep the noise down, and scanning across everywhere secrets actually leak.
Frequently asked questions
What should I do first if an API key is leaked?
Revoke the key immediately. A leaked key is live until the provider invalidates it. Then assess what it could access, purge it from code and history, and rotate related credentials.
Can I just delete the API key from the repo and move on?
No. Deleting it from current code does nothing about the copy in git history, and an unrevoked key still works. Revocation is the security fix; removing it from code is hygiene. Both, in that order.
How do I know what a leaked API key can access?
Check the key's permissions at the provider, then audit what it actually touched through activity logs. That is the blast radius — which systems, data, and accounts the key could reach before revocation.
How long do I have to respond to a leaked API key?
Assume zero minutes. Leaked keys are often tested within minutes of exposure. Treat every leak as already-exploited until your audit says otherwise.
How do I prevent API key leaks in the future?
Pre-commit scans, push protection, regular full-history scanning, short-lived credentials instead of long-lived keys, and scanning beyond repositories — chat, tickets, wikis, and logs.