What Happens When an API Key Leaks — and What to Do in the First Ten Minutes
Scanners find newly exposed keys within minutes. The three ways keys escape, the three layers that limit the damage, and why revoking is always the first move.
Why deleting it does not help
A key committed to a repository stays in the git history after you delete the file, and if the repository was ever public, it may already be cloned, forked, or mirrored. Rewriting history does not recall those copies. This is why revoke comes first and cleanup second: only revocation actually invalidates the credential, and every minute before that is exposure.
Never call a provider directly from a browser
A key shipped to the frontend is public by construction — no amount of obfuscation changes that, because the request has to carry the credential and the user can read it. The pattern is a thin backend endpoint that holds the key and forwards the request. That is also where you enforce your own per-user limits, which the provider cannot do for you.
Separate keys are worth the small overhead
One key per environment and per project sounds fussy until the first incident, when the choice is revoking one key or breaking everything at once. It also makes usage attributable: when spend jumps, per-key figures tell you which project did it. Most providers make key creation free and instant, so the only cost is a little organization.
Spending caps are the last wall
Detection is never instant, so a ceiling is what decides whether a leak costs you a small amount or a large one. Set an account-level cap and, where the provider supports it, a per-key cap. Alert on **daily** spend rather than monthly — a monthly figure tells you about an incident that already finished. This is the single highest-value fifteen minutes in this article.
Checking whether you have already leaked one
Search your repository history for the key prefixes your providers use, not just current files. Check any deployed frontend bundle for the same patterns. Review CI logs, which often echo environment variables in error output. Then look at your own usage history for calls you cannot account for — unfamiliar times of day and unexpected models are the usual signals.
The order of operations after a leak
**1. Revoke the key.** First, before anything else, even if you are not certain. A revoked key costs you a redeploy; a live leaked key costs you money. **2. Issue a new one** and deploy it from a secret store, not a file. **3. Review usage** for the exposure window and quantify what was used. **4. Then clean up** the repository or bundle. **5. Add the guard** that would have caught it — secret scanning in CI takes minutes to enable and prevents the repeat.
How keys escape and what stops each
| Route | Why it is missed | What prevents it |
|---|---|---|
| Committed to a repo | Deleting the file leaves the history | Pre-commit secret scanning; env files ignored |
| Hardcoded in frontend | It works, so nobody looks | Never call the provider from the browser — proxy it |
| Pasted in public | A screenshot feels harmless | Redact before sharing; rotate if unsure |