I accidentally committed an API key — what now?

Take a breath. This happens to experienced engineers — tight deadlines, a rushed git add ., a “temporary” debug file. What matters is order of operations. Doing the wrong step first (for example, only rewriting Git history without revoking the key) leaves you exposed.

This playbook is provider-agnostic where possible and points to official GitHub documentation for history rewriting.

Phase 1 — Assume compromise (minutes 0–30)

1. Revoke or rotate the credential immediately

For most SaaS APIs:

  • Go to the vendor dashboard → API keys / secrets.
  • Revoke the leaked key.
  • Create a new key with the minimum scope required.
  • Update deployment and local environments with the new value.

Why first? GitHub, mirrors, and local clones may already have copied the object. History rewriting is slow and never guaranteed to reach every copy of the universe.

2. Classify exposure

Answer honestly:

  • Was the repo public at any time?
  • Was it private but with many collaborators, contractors, or former employees?
  • Did CI upload artifacts or logs that contain the secret?
  • Was the commit pushed or only local?

The wider the exposure, the stronger you should assume active abuse until logs say otherwise.

3. Check vendor abuse guidance

Many providers publish “what to do if your key is exposed” runbooks. Follow them for fraud monitoring, IP restrictions, and scope reduction.

Phase 2 — Remove the secret from future commits

1. Delete the file or replace the value in the working tree

# If .env was committed
git rm --cached .env   # stop tracking; keeps local file if you still need it
# or delete the secret from the tracked file entirely

Commit a message that does not repeat the secret:

git commit -m "Remove accidentally committed environment file (rotated credentials)"

2. Ensure .gitignore prevents recurrence

See patterns in Keep secrets out of Git.

Phase 3 — Purge from history (high coordination)

If the secret ever existed in a pushed branch, consider history rewriting. GitHub’s supported path uses git filter-repo.

Official guide:
Removing sensitive data from a repository

Why not just git revert?

git revert adds a new commit; old commits still contain the blob. Automated secret scanners and clones can still extract it.

Outline (read the full GitHub doc before running)

  1. Install git-filter-repo.
  2. Clone a fresh bare mirror or follow GitHub’s recommended workflow.
  3. Remove the offending file(s) or replace strings across history.
  4. Force-push all affected branches and tags (requires admin coordination).
  5. Ask collaborators to re-clone or reset carefully — old SHAs are invalid.

GitHub secret scanning alerts

If GitHub notified you, follow their remediation links. Secret scanning exists to shrink the window between push and rotation. Introduction:
About secret scanning

Phase 4 — Hunt for copies outside Git

Check:

  • CI caches and build artifacts
  • Error trackers (Sentry breadcrumbs sometimes capture env)
  • Crash dumps
  • Backups (Time Machine, disk images)
  • Internal wikis or tickets where someone pasted “just the error message”

Phase 5 — Prevent the next incident

Technical controls

  • Pre-commit secret scanning (gitleaks, etc.) — see keep secrets out of Git.
  • GitHub push protection for supported patterns.
  • Separate test and live keys; never reuse production credentials on laptops without need.

Workflow controls

  • Store developer secrets in a local vault (e.g. PassStore) instead of long-lived .env files copied between machines.
  • Prefer short-lived credentials where your stack allows OIDC or similar.

Provider-specific quick notes

These change UI frequently — always read the vendor’s current security page.

NPM publish tokens

If an npm automation token or legacy publish credential leaked, revoke in npmjs.com account Access Tokens, rotate any CI NPM_TOKEN, and audit published package versions for unexpected releases. npm docs: About access tokens.

PyPI API tokens

Revoke in PyPI Account settings → API tokens; regenerate and update Twine, CI, and .pypirc (never commit). PyPI help: API tokens.

Slack / Discord bot tokens

Revoke the app token in the provider dashboard; assume workspace messages may have been exfiltrated if the key had broad scopes. Slack: Rotating tokens.

AWS AKIA... access keys

Disable the key immediately, review CloudTrail for first use, and prefer replacing with OIDC for GitHub Actions — GitHub OIDC to AWS.

What if someone used the key?

Symptoms depend on the service: unexpected charges, new cloud resources, outbound spam, data exfiltration.

  1. Revoke remaining access.
  2. Audit vendor logs (API calls, admin actions).
  3. Notify your security / legal chain according to company policy.
  4. Document timelines for post-incident review.

Related reading