Deleted the leaked API key? It may still work.

If an API key appears in a commit, deleting the line from the latest version does not make the old value secret again. Copies may remain in Git history, forks, build logs, caches or a developer’s clone. More importantly, the service that issued the key may continue accepting it. GitHub’s secret-scanning guidance says to treat a committed secret as compromised and prioritize rotating it; rewriting history can be time-consuming and is often unnecessary once the credential has been revoked.

Start with the provider that issued the key. Disable or revoke the exposed credential, then create a replacement with only the permissions the application needs. If a service offers overlapping credentials, update the application and its deployment configuration to use the new one before retiring the old value. Test the change through the normal release path, because a key can be read by jobs, scheduled tasks or other services that are not obvious from the source file.

After containment, check where the key was used and whether access logs show activity you cannot explain. GitHub recommends reviewing services that use the old token and checking security logs for unauthorized use. AWS’s migration guidance similarly separates three tasks: move the secret out of source code, update the application to retrieve it from a secrets manager, and revoke and replace the original credential at its issuer. Storing the replacement securely prevents the same exposure pattern; it does not invalidate the leaked value by itself.

Then address the repository copy. Remove the secret from the current tree, inspect other branches and automation, and consider history cleanup if the exposure creates continuing risk or policy requires it. Coordinate that rewrite because collaborators may need to rebase or reclone. A scanner alert closing as resolved is not evidence that every downstream copy was erased; the key’s revoked status and the consuming service’s updated configuration are the important checks.