You deleted the leaked key's repo. The key still works.

It’s the small lurch you feel when you spot an API key sitting in a commit. Maybe a config.js with a live token in it, or an .env that was never meant to be tracked, pushed to a repo that turned out to be public. The instinct is immediate and reasonable: get it out of there. So you delete the file, push the change — or if the repo was only ever a throwaway, you delete the whole repository. The offending line is gone from the page. Crisis handled.

Except the key still works.

Deleting where a secret was published does nothing to the secret itself. The key, token or password is a credential the service still recognises; removing the file that displayed it doesn’t tell the service to stop honouring it. Anyone who copied it in the window it was exposed — and automated scanners copy public commits within minutes — holds a working credential, and your tidy-up did nothing to take it away from them. Worse, on most Git hosts the value lingers in the repository’s history and in cached views even after you delete the file, so it may not even be as gone as it looks.

That’s the quiet failure: cleanup feels like remediation, but the only thing that actually closes the door is rotating the credential — and that’s the step people skip. It’s why GitGuardian’s State of Secrets Sprawl 2026 report found that 64% of the secrets it had confirmed as leaked and live back in 2022 still worked in January 2026 — four years on. Nobody ever revoked them.

Why it stays invisible

Nothing breaks when a leaked key keeps working. The service doesn’t email you, the key doesn’t stop functioning, your app carries on exactly as before. From your side there’s no symptom at all — which is precisely why the rotation step feels optional. You dealt with the visible thing (the file on the page), and the invisible thing (the credential’s continued validity) leaves no trace to remind you it’s still open.

Meanwhile the other side is anything but quiet. Public code hosts are scanned continuously; a secret pushed to a public repo is often detected and harvested by automated bots within minutes, long before you notice and delete. So by the time you’re removing the file, the assumption has to be that the value is already in someone else’s hands. Deleting it is closing a window the horse left through some time ago. And because a valid cloud key or database password can be quietly used — to run up charges, read data, or move sideways into other systems — without ever tripping an alarm, the exposure can sit there earning nobody’s attention for months or years.

Find it yourself

You can find exposed secrets and, more importantly, rotate the live ones in about ten minutes. Some of this uses the command line; there’s a no-command-line route at each step.

1. Search your own repositories for the usual shapes. From a checkout of a repo, run a quick search across its whole history, not just the current files:

   git log -p | grep -Ei "api[_-]?key|secret|token|password|BEGIN (RSA|OPENSSH) PRIVATE KEY|AKIA[0-9A-Z]{16}"

   AKIA… is the giveaway prefix of an AWS access key; the rest catches common labels. No command line? On GitHub, use the search box inside each repository and search for AKIA, api_key, secret and BEGIN PRIVATE KEY, then open the repository’s Security tab and look under Secret scanning, which flags known credential formats automatically. If that section is missing, the feature (GitHub currently calls it Secret Protection) is free for public repositories and can be switched on under Settings → Advanced Security — though GitHub does move these labels around.

2. Assume anything you find in history is compromised. It doesn’t matter that the file was deleted last year — if a real credential ever appeared in a public commit, treat it as leaked. Make a list of each live secret you find: what it is, and which service issued it.

3. Rotate each one at the source — this is the actual fix. Go to the service that issued the credential and generate a new one, then revoke the old. This is the step that closes the door; everything before it is just finding the doors. A few common ones:

   • AWS: IAM → Users → the user → Security credentials → create a new access key, update your app, then deactivate and delete the old key.
   • Google Cloud: IAM & Admin → Service accounts → the account → Keys → add a new key, deploy it, then delete the old key.
   • A third-party API (Stripe, SendGrid, a database, etc.): open its dashboard’s API-keys or credentials page, roll / regenerate the key, and delete the exposed one.

4. Don’t rely on scrubbing history instead of rotating. You can rewrite Git history to purge a value, but it’s fiddly, it doesn’t help if the secret was already copied, and it’s not a substitute for rotation. Rotate first, always; clean history afterwards only if you need to.

The fix

Rotating today’s leaked keys closes today’s doors. The point of the fix is to stop new ones opening.

Keep secrets out of code in the first place. Load credentials from environment variables or a secrets manager (a cloud provider’s own, or a tool like your team already uses), not from files in the repo. The secret your code never contains is the secret you can never leak.

Add a .gitignore and a pre-commit guard. List .env and other secret files in .gitignore so they can’t be committed by habit, and add a pre-commit scanner (there are well-known open-source hooks that block a commit containing something that looks like a key) so a slip is caught on your machine before it ever reaches the host.

Turn on the host’s secret scanning. GitHub, GitLab and others can watch pushes for known credential formats and alert you — some even notify the issuing provider so the key can be revoked automatically. It’s a safety net, not a first line, but it’s free and worth having on.

Prefer short-lived credentials where you can. A key that expires on its own, or a short-lived token issued per-session, limits the damage of any future leak to a small window instead of “forever until someone remembers”.

The reassuring part is that the fix is entirely in your hands and quick per key: find it, generate a new one, revoke the old. Do that once for the secrets already out there, put the guards in place so the next one never leaves your machine, and the leak that used to mean “live credential, indefinitely” becomes “a key that stopped working the moment you rotated it”.