Revoke or rotate the key first, before anything else. Once rotated, it can no longer be used. Then check the provider's logs for misuse, replace the key in your deployments, and then decide whether cleaning git history is worth the effort. Rewriting history is usually optional.
Minute 0 to 10: rotate
GitHub's guidance on removing sensitive data states that for a secret "you need to revoke and/or rotate that secret" as the first step. Do this in the provider console. Create the new key, update your applications and CI, then disable the old one. If you cannot update everything fast, disable the old key anyway and accept a short outage. A short outage is better than an open door.
Minute 10 to 30: look for misuse
Open the provider's activity or billing logs for the period between the commit and the rotation. Look for requests from unfamiliar IP addresses, regions you do not use, new resources you did not create, and unexpected spend. Note what you find, even if it is nothing, with the time you checked.
Minute 30 to 45: replace and verify
- Confirm production is using the new key.
- Search your other repositories and config files for the same key, because copies get around.
- Check whether the key had broad permissions. If so, a narrower replacement is better than a like-for-like swap.
Minute 45 to 60: decide about history
GitHub notes that after rotation, "going through the extra steps to rewrite the history and remove the secret may not be warranted". Rewriting history changes commit hashes, can break pull request diffs and cannot delete other people's clones or forks. If the repository is private and the key is dead, you may reasonably leave history alone. If you rewrite, tell collaborators first.
Prevent the next one
GitHub push protection blocks hardcoded credentials before they reach a repository and explains why. User-level push protection is on by default on GitHub.com for pushes to public repositories, while repository-level protection requires GitHub Secret Protection. Beyond that, keep secrets in environment variables or a secrets manager and add a pre-commit check.
Write three lines afterwards
What leaked, when you rotated it and what you found in the logs. This is your incident record, and it helps if a customer or auditor asks later.
Quick check
Is deleting the commit enough?
No. Anyone who cloned or forked, and any cache, may still hold it. Rotation is what makes the key useless.
Should I tell customers?
If the key could reach customer data and logs show misuse, yes, and check any contract or legal duty. If rotation was fast and logs are clean, record it and move on.
Safeguard policies and gates can add checks to pull requests, and a free scan of your dependencies is available at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
