A leaked API key is not a hypothetical risk that lives in a compliance spreadsheet — it is a working credential that anyone who finds it can use immediately. In 2022 Toyota disclosed that source code for its T-Connect app had been published to a public GitHub repository by a subcontractor and sat there for nearly five years with a hardcoded access key to a customer-data server, exposing roughly 296,000 email addresses before the key was finally revoked. In January 2023 CircleCI told every customer to rotate all secrets stored in the platform after malware on an engineer's laptop stole a session token and gave attackers access to environment variables and keys. The lesson from both is the same: once a secret is exposed, the only safe assumption is that it has been copied, and the clock starts the moment it leaks. This guide is the playbook for what to do next.
How API keys leak in the first place
Most leaks are not sophisticated. Keys end up committed to git history in a .env file, pasted into a Slack message or support ticket, printed to CI logs by a debug statement, baked into a Docker image layer, or hardcoded in a mobile app that anyone can decompile. Public repositories are scraped continuously — automated bots clone new commits within seconds of a push and test any credential-shaped string they find. GitGuardian's research has consistently found millions of new secrets leaked to public GitHub every year, and the median time from a valid AWS key hitting a public repo to first malicious use is measured in minutes, not days. Private repositories are not safe either: the Uber 2016 breach began when attackers found AWS credentials in a private GitHub repository used by engineers, and used them to reach an S3 bucket holding 57 million records.
The zero-downtime rotation playbook
The cardinal rule of rotation is create the new credential before you destroy the old one. Deleting first causes an outage; overlapping the two lets you cut over cleanly. Here is the pattern for an AWS IAM user, which generalizes to almost any provider:
# 1. Create the replacement key BEFORE touching the old one
aws iam create-access-key --user-name deploy-bot
# 2. Push the new value into your secrets manager (single source of truth)
aws secretsmanager put-secret-value \
--secret-id prod/deploy-bot \
--secret-string '{"AWS_ACCESS_KEY_ID":"AKIANEW...","AWS_SECRET_ACCESS_KEY":"..."}'
# 3. Redeploy so services pick up the new value, then DEACTIVATE (not delete) the old key
aws iam update-access-key --user-name deploy-bot \
--access-key-id AKIAOLDKEY --status Inactive
# 4. Watch for errors for a rotation window, then delete permanently
aws iam delete-access-key --user-name deploy-bot --access-key-id AKIAOLDKEY
For a provider without a two-key model (many SaaS APIs), roll the new key into your secret store first, deploy, then revoke the old one through the provider console or API. Always verify the old credential is actually dead rather than assuming the revoke succeeded:
# Confirm a revoked GitHub token now returns 401
curl -sS -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $OLD_TOKEN" https://api.github.com/user
# Expect: 401
Then close the loop on the source of the leak. Purge the secret from git history (a plain git rm does not remove it from past commits):
# Rewrite history to strip a leaked file, then force-push
git filter-repo --path config/secrets.yml --invert-paths
git push --force --all
Finally, review provider audit logs for the exposure window — CloudTrail for AWS, the audit log for GitHub — to determine whether the key was actually used before you killed it. Revocation stops future abuse; the audit log tells you whether you also have a breach to report.
Rotation checklist
| Step | Action | Why it matters |
|---|---|---|
| 1 | Create replacement credential first | Avoids the outage that tempts teams to delay rotation |
| 2 | Store the new secret in a manager, never in code | Prevents an immediate re-leak of the fresh key |
| 3 | Deploy, then deactivate the old key | Deactivate is reversible; delete is not |
| 4 | Verify the old credential returns 401/403 | Confirms the revoke actually took effect |
| 5 | Purge the secret from git history | A committed key stays reachable until history is rewritten |
| 6 | Review audit logs for the exposure window | Distinguishes a scare from a reportable breach |
| 7 | Add detection so the next leak is caught pre-merge | Stops the same mistake recurring |
How Safeguard's secret scanning helps
Rotation is only the second half of the problem; the first half is knowing a key leaked at all. Safeguard's secret scanning runs across your repositories and full git history — not just the latest commit — and surfaces exposed credentials with the file, commit, and author that introduced them, so you are not diffing history by hand during an incident. Because a flat regex match produces noise, Griffin AI validates candidate secrets and classifies each by provider and blast radius, letting you rotate the live, high-privilege keys first instead of triaging test fixtures. Developers catch leaks before they ever reach a shared branch by running the Safeguard CLI locally and in pre-commit, and when a hardcoded secret sits alongside a fixable configuration issue, auto-fix opens a pull request that removes it and wires in a secrets-manager reference. Because secret exposure and vulnerable dependencies show up in the same software composition analysis view, incident response starts from one prioritized list instead of five disconnected dashboards.
Bring continuous, prioritized secret and dependency scanning to every repository — get started free or read the documentation.
Frequently Asked Questions
Do I really need to rotate a key that only leaked to a private repository?
Yes. Private does not mean unreachable — the Uber 2016 breach and the 2024 Sisense incident both began with credentials sitting in private source control that attackers reached through other means. Treat any secret that left a secrets manager as compromised, because you cannot prove it was never copied. Rotation is cheap; assuming exposure and being wrong is not.
Should I delete the leaked key immediately or deactivate it first?
Deactivate first whenever the provider supports it. Immediate deletion risks an outage if a service you forgot about still uses the key, which pressures teams into delaying rotation altogether. Deactivation stops the key working while remaining reversible, so you can safely watch for errors during the rotation window and then delete once traffic is clean.
Is removing the secret from the latest commit enough?
No. Git preserves every historical version, so a git rm on the current file leaves the secret fully readable in earlier commits. You must rewrite history with a tool like git filter-repo and force-push, and you must still rotate the key, because it was public long enough to be scraped regardless of the cleanup.
How fast do leaked keys actually get abused?
Fast enough that manual response is too slow. Automated bots scan new public commits continuously and test credential-shaped strings within seconds to minutes of a push. This is why detection needs to happen before code reaches a shared branch, and why rotation should be a rehearsed, scripted procedure rather than something you improvise during an incident.