Safeguard
Incident Analysis•

What to Do When an API Key Leaks: A Developer Playbook

When an API key leaks, revoke it first, rotate to a new one, remove it from code and logs, check usage for abuse, then add scanning so it cannot recur.

Safeguard Security Team
3 min read

When an API key leaks, revoke it immediately, rotate to a new key, remove the old one from code and logs, review the provider's logs for misuse, and add secret scanning so it cannot happen again. Do not wait to clean up git history first, because the key stays usable until it is revoked.

Key takeaways

  • Revoke first. Cleanup comes second.
  • Deleting a commit or running git revert does not remove the secret from history.
  • Check access logs for the whole exposure window.
  • Push protection and pre-commit hooks stop most repeats.
  • Write down what happened while it is fresh.

What do I do in the first ten minutes?

Revoke the key at the issuer. OWASP's guidance puts the order as revoke, rotate, delete, log. Speed matters, since a quick response is among the most important factors. Restarting your app does nothing for a stolen key, because it stays valid until the backing service expires or revokes it.

GitHub's secret scanning can report and revoke supported credentials found in GitHub repositories, and exposures elsewhere can be submitted for revocation through the REST API for supported token prefixes such as ghp_ and github_pat_.

How do I rotate to a replacement?

Create a new key, update the consumers, test, then confirm the old key is dead. If revoking would break production, run both briefly, but keep that window short. Full steps are in how to rotate secrets safely.

How do I remove the key from git history?

Use git filter-repo, as GitHub's guidance suggests. If changes are not pushed, undo them locally. Do not use git revert: it leaves the original commit in history, so the secret remains accessible. Anyone who cloned or forked may still hold a copy, which is why revocation matters more than scrubbing.

How do I find out whether it was abused?

Check the provider's audit and usage logs for the time between exposure and revocation. Look for unfamiliar IP addresses, regions, unusual call volumes and new resources. Record who had access, when the key was used and when it was last rotated, as OWASP advises.

How do I stop it happening again?

  • Turn on push protection. GitHub secret scanning checks for supported secrets before they are committed, and logs bypasses.
  • Add a pre-commit secret check: how to set up pre-commit security checks.
  • Prefer short-lived credentials so a leak expires on its own.

See what secret scanning finds in Safeguard's interactive demo:

Click through it at your own pace, or open it full screen.

Frequently asked questions

Is deleting the commit enough?

No. The key may already be copied, and history can still expose it. Revoke it.

Should I revoke before or after rotating?

Create the replacement quickly, but do not delay revoking a leaked key. If a short overlap is unavoidable, keep it brief.

What if the repository was private?

Treat it as leaked anyway. Anyone with access, and any tool that cloned it, may have the key.

How do I know the key was used by someone else?

Review the provider's usage logs from exposure to revocation for unfamiliar sources or volumes.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.