Leaked secret emergency checklist

A do-it-now checklist for a leaked API key, token, or password: contain it, check for misuse, and prevent a repeat. Replace the key first. Optionally, clean it out of your git history.

Incident response. June 24, 2026

Before anything else: replace the key. Invalidate the exposed key at the service it came from and create a new one. Nothing else on this list makes the exposed value safe. This does, no matter who already has a copy.

1. Contain#

Do this now, before you attempt any other remediation.

Replace the key. Invalidate the exposed key at the service it belongs to, then create a new one to use instead. Point your app and build system at the new value, kept in the environment your program reads at startup or in a separate tool for secrets, not written into the code.

2. Assess#

Once the old key is deactivated, find out whether it was used.

Assume it was already found. Automated programs find exposed keys within minutes. Check the service's activity log (AWS, for example, calls its log CloudTrail) for any activity you do not recognize. If you find misuse, treat it as an incident: review everything the key could reach, look for unexpected resources or charges, and lock down what is affected.

3. Sweep and prevent#

Finish the response, and make sure it does not happen again.

Scan the whole repository, including its git history, for any other secrets: trestle --deep . Trestle Pro adds remediation guidance with --explain. Replace anything else the scan finds, the same way as step 1. Move secrets out of the code, into the environment your program reads at startup or a separate tool for secrets, and add the file that holds them to your .gitignore (the list of files git is told to never track). Add a check that runs on every commit so a secret cannot be committed again in the future: trestle install .

4. Optionally clean it out of your history#

Optional cleanup, not the fix. Rewriting history changes every commit, so everyone with a copy of the repository has to discard it and clone again. Only worth the disruption if the key must not stay in the history.

Confirm it is still there with trestle --deep . Deleting it in a later commit does not remove it; the older version still holds the key. Remove it from every past commit with a history-rewriting tool like git-filter-repo (git filter-repo --invert-paths --path PATH/TO/FILE ) or BFG Repo-Cleaner. Overwrite the copy on your git host (GitHub, for example) with git push origin --force --all and tell collaborators to download it fresh so they do not put the secret back. Accept what you cannot reach. Forks, other people's copies, and anything GitHub has cached may still hold the old commit. Replacing the key in step 1 is what protected you, not this.

The one line that matters most is at the top: replace the key first. Everything else on this list limits the damage or prevents the next leak. Only a new key makes the exposed one safe.