Sooner or later a key ends up where it should not be. A developer commits it to a repository, someone pastes it into a chat with an AI assistant to explain an error, a ticket quotes a configuration file, or a debug log prints the whole request. Nobody was malicious, and the key still works.
The first question is usually the same: do we revoke it now, or first find out whether anyone used it? This article argues for revoking, gives an order of steps for the first hour, and says who does what and when the case is closed. It is written for operations and technology leads in smaller companies, where many people hold keys.
Revoke first, investigate second
The guidance we checked is consistent. GitHub's remediation tutorial says to consider any leaked secret immediately compromised, and that removing it from the code, pushing a new commit or recreating the repository does not stop it being exploited. The OWASP Secrets Management Cheat Sheet puts revocation first in its containment steps. Stripe tells users to assume a found key has been exposed and compromised.
The reasoning is simple. Investigating takes hours while the key stays valid. Revoking takes minutes and does not destroy evidence, because the provider's usage logs stay where they are. GitHub adds that automated scanners can locate public secrets in minutes; that is the vendor's general statement, not a measurement for your case.
One exception is a key that production depends on. GitHub's advice there is to create a new secret with the same permissions, move the application to it, then revoke the old one. That is still revoke-first, ordered to avoid an outage.
Lesson: the question is never whether to revoke, only whether the new key must be ready first.
Five roles, named before the incident
A leak at 4 pm on a Friday goes badly when nobody knows who may press the button. Write these names on one page:
- Finder. Whoever sees the key. They say where it is and do not copy it anywhere.
- Key owner. Whoever created it and knows what uses it. GitHub suggests CODEOWNERS and
git log -Sto find them. - Provider admin. Someone who can revoke and create keys in the provider's console. In small companies this is often one person, which is a single point of failure.
- System admin. Whoever controls where the key leaked: repository, chat workspace, ticket system, log store.
- Case lead. One person, usually operations, who runs the clock, decides and writes the record. They need not be technical.
OWASP asks for the same shape: documentation should tell everyone in the chain whom to alert, what to contain and what to log. If you have a routine for the first ten minutes after a phishing report, reuse its structure.
Lesson: a revocation that waits for the one person with provider access is a delay you chose in advance.
The first hour, step by step
The times are our suggestion, not a standard. Shorten them if the key is live in production or in a public place.
Minutes 0 to 10: record, then revoke.
- The finder tells the case lead where the key is, with a link or path, not the key itself.
- The case lead opens a record: time found, location, provider, the key's name or last characters, who is on the case. It becomes your timeline.
- The key owner checks scope and last use in the provider console. GitHub treats validity, public exposure and dependent services as the first risk questions.
- The provider admin revokes the key, creating the replacement first if production needs it.
Minutes 10 to 30: rotate and restore.
- Put the new key in a secrets store or the platform's secret settings, not in code.
- Update every system that used the old key. GitHub suggests searching code, issues, pull requests, deploy keys and variables, because the same key is often in several places.
- Test the services, then confirm the old key now fails.
Minutes 30 to 60: check what happened.
- Review the old key's usage across the whole exposure window. Anthropic recommends its Logs and Usage pages and spend limits as a safeguard; AWS documents CloudTrail for access key usage. Look for unfamiliar addresses, unusual volume, services you do not use and odd hours.
- Check the leak location: forks of the repository, who could read the chat or ticket. This sizes the exposure window; it does not change the decision to revoke.
- Ask the key owner what else the key could reach, such as data or accounts.
Lesson: the order is record, revoke, rotate, check, because each step depends on the one before it.
Deleting the evidence is not the fix
Teams often spend the hour cleaning: removing the file, rewriting git history, deleting the chat message. It feels like action and it is secondary.
GitHub's documentation on removing sensitive data says that for a secret the first step is to revoke or rotate it, after which rewriting history may not be warranted. It lists what stays reachable after a force push: clones and forks, cached views by commit hash, and pull requests that reference the commits. OWASP adds that squashing history breaks links to other commits.
So clean up in order of value. Remove the key from live files and pipeline settings. Ask the chat or ticket owner to delete the message, knowing that deletion does not prove nobody saw it. Rewrite repository history only for a compliance reason and with the repository's security lead.
Lesson: clean-up protects tidiness; only revocation protects the account.
When the recommendation does not fit
Revoke-first is the default, not a law. Three situations need care.
A key shared across many systems. If nobody has a list of where it is used, revocation will break things you cannot predict. Still revoke, expect an outage, and treat the missing list as the real finding.
A key that was never secret. Stripe distinguishes publishable keys, safe for webpages and apps, from secret keys that stay on the server. Confirm which you have; when in doubt, treat it as secret.
A provider without good logs. If key-level usage is not visible, you cannot prove abuse did not happen. Record "revoked, usage could not be verified" and watch billing and account activity for longer.
The uncertainty is real. We found no reliable public figure for how fast a leaked key is abused in a company your size, and vendor statements on speed describe public repositories. A private location lowers the risk without removing it, and GitHub still says to remediate medium and low risk secrets.
Lesson: a default is valuable because you know in advance which situations will bend it.
When the case is closed
Close the case only when each of these is true and written in the record:
- The old key is revoked and a test call with it fails.
- The new key is in the secrets store and every system that used the old one works.
- Usage during the exposure window is reviewed, and the record says what was found or that it could not be checked.
- The leak path has a fix with an owner and a date: a pre-commit check, push protection, a rule about what goes into AI chats, a log filter.
- Those involved know what happened, without blame. A one-page blameless review is enough.
GitHub says push protection blocks pushes containing detected secrets before they reach the repository; availability depends on your plan, so check current terms. For leak paths involving GitHub Actions logs, our GitHub Actions log secret scanning rollout guide covers the preview’s detection limits, enterprise scope and alert review ownership. Prevention is covered in our articles on credentials for AI agents and on keys when an employee leaves.
Lesson: a case is closed by evidence in the record, not by the alarm going quiet, so this week write the one-page version of this plan, run it once on a dummy key, and if you want help listing the keys your AI tools and integrations use, White Veil Industries covers that in AI consulting.
Sources
Living pages, accessed 4 November 2026; check the current text before relying on a detail.
- GitHub Docs, "Remediating a leaked secret in your repository" (2026): link. Compromise statement, scanner speed (GitHub's claim), replace-then-revoke, access checks.
- GitHub Docs, "Removing sensitive data from a repository" (2026): link.
- GitHub Docs, "About push protection" (2026): link.
- OWASP, "Secrets Management Cheat Sheet", revocation and incident response: link.
- Stripe Docs, "Best practices for managing secret API keys" (2026), vendor guidance: link.
- Anthropic Support, "API key best practices", vendor guidance: link.
- AWS, "Managing access keys for IAM users", monitoring: link.
Lesson: keep the provider's current revocation page beside each key, because those steps change faster than your plan.
