What to do when an API key leaks
A key was committed to a public repository, pasted into a ticket, or printed in a log. It may already have been used.
Issue a replacement first, deploy it, then revoke the leaked key — in that order, so the service never runs without a working credential. Then audit what the key did while it was exposed. Rotating before deploying causes an outage; revoking last means the window stays open slightly longer but nothing breaks.
Order matters more than speed
The instinct is to revoke immediately. That stops the attacker and everything else at the same time, and the resulting outage often delays the rest of the response. Issue, deploy, verify, then revoke. If the key is known to be actively abused, invert this and accept the outage — but make that a decision rather than a reflex.
Rotating what the key could reach
A key is rarely alone. If it could read configuration, everything in that configuration is potentially exposed too. Enumerate what the credential unlocked and rotate outward from there, rather than treating the leaked string as the whole incident.
Auditing the exposure window
Establish when the key was first exposed and pull its usage from that moment. Requests from unfamiliar addresses, at unusual hours, or against endpoints the legitimate client never calls are the signal. Absence of evidence here is weak evidence: many systems do not log per-key usage at all, which is itself worth fixing.
Removing it from history
Deleting a secret in a new commit leaves it in history and in every clone. Treat any key that reached a repository as compromised permanently and rely on rotation rather than on rewriting history, which does not reach forks or caches.
Response order
Response order
| Step | Why this position |
|---|
| 1. Issue a replacement | Nothing else is safe until a working credential exists |
| 2. Deploy and verify | Confirms the new key works before the old one dies |
| 3. Revoke the leaked key | Closes the window without causing an outage |
| 4. Audit usage | Determines whether this was an exposure or a breach |
| 5. Rotate what it could reach | A key that read config exposes more than itself |
Key facts
- Issue and deploy a replacement before revoking a leaked key, so the service is never left without a working credential.
- A secret committed to a repository stays in history and in every clone, so rotation is the remedy rather than rewriting history.
- A leaked key exposes everything it could read, so the incident includes the credentials that key could reach, not only the key itself.
- Absence of suspicious usage is weak evidence when per-key usage is not logged, which is a gap worth closing during the response.
- Revoking first is correct only when the key is known to be actively abused, and that should be a decision rather than a reflex.
Frequently asked questions
The repository was private. Is rotation still necessary?
Yes. Private repositories are cloned, forked, backed up and read by integrations, and access changes over time. Once a secret is in version control the cost of assuming it is safe is much higher than the cost of rotating.
How do I stop this recurring?
Scan on commit rather than after the fact, and prefer credentials that cannot be pasted — short-lived tokens, scoped keys, and keys bound to an identity so an exposed one has a smaller blast radius.
Should agent keys carry management permissions?
Never. A credential that can mint further credentials turns a single leak into an unbounded one, because revoking the original does not revoke what it created.
Machine-readable copy of this page:
/guide/respond-to-a-leaked-api-key.md