Order matters: revoke first, clean second. Reversed, cleanup takes half an hour and the key stays valid the whole time.
Step one: revoke now (two minutes)
- Disable or delete the key in the gateway console.
- Issue a new one.
- Keep the new one in an environment variable or a secret manager, never in a file.
Do these three before touching the repo. The window between a leaked key being scraped and abused is often tens of minutes.
Step two: clean history, not just the file
Delete the line and commit again and the key is still in history: anyone who clones can run git log -p. Clean the history:
git log --all -p -S 'sk-' --oneline | head # confirm which commits hold it git filter-repo --path-glob '*.yaml' --invert-paths # or rewrite selectively with filter-repo
Rewriting history affects every collaborator, so notify first and take a full mirror backup before you start.
Step three: assume it leaked
Even in a private repo, assume compromise. Everyone who ever cloned has that history locally and you cannot recall it. Revocation is the only reliable stop.
Step four: check for use
- Look for abnormal peaks in gateway usage.
- Check the calling IPs recorded for that key, if any.
- Treat anomalies as a security incident, not just a key rotation.
Step five: prevent the next one
- Add a pre-commit hook that scans for
sk-style prefixes. - Separate templates from credentials: templates in the repo, values injected from the environment.
- Put
.credentials.yamlin.gitignore— it is a key, not a config file.