The First Hour After a Key Leaks

Automated scrapers watch the public commit stream and act on new credentials within minutes. By the time a human notices, the useful question is no longer how the key got there. It is what is still valid, and what has already been used.

This is a runbook for the first hour. It assumes one leaked credential in a repository you control, and it puts the steps in the order that limits damage rather than the order that feels productive.

Minute 0 to 10: revoke

Invalidate the credential at the provider. Not rename, not comment out, not remove from the file. Revoke. Until the key is dead, every other step is decoration, including the commit that deletes it.

If revoking immediately would break production, jump to the dual-key path below, but keep the clock running. A short outage is almost always cheaper than an active credential in public.

Minute 10 to 25: issue a replacement

Create the new credential, store it in your secret manager or CI secret store, and deploy. If the service tolerates two active keys, issue the new one first, deploy everywhere, verify traffic has moved, then revoke the old one.

Keep the overlap window down to minutes rather than days. A dual-key window is a tool for avoiding an outage, not a way to defer the revocation indefinitely.

Minute 25 to 45: find out what was used

Pull the provider audit log for the exposure window and look for calls you cannot account for:

• Requests from unfamiliar IP ranges or regions you do not deploy to.

• Sudden spikes in usage, especially on expensive operations.

• New resources created, new keys issued, or permission changes.

• Reads of data the leaked credential could technically reach but never normally touches.

For cloud keys, check billing as well as activity. Crypto mining on a stolen key shows up as cost long before it shows up as an alert.

Minute 45 to 60: contain the blast radius

A key rarely leaks alone. The same commit, the same file, or the same habit usually produced others.

1. Scan the whole repository and its history, not just the file you found.

2. Check whether the same secret was reused in other projects or environments.

3. Confirm the file is untracked so the next commit does not repeat it.

4. Write down what leaked, when it was revoked, and what the audit log showed.

The first hour has one job: make the exposed credential worthless. Everything else is recovery, and recovery is easier when the key is already dead.

What does not belong in the first hour

History rewriting, the blameless retro, and the process change all matter, and none of them are urgent. Rewriting history before rotating is the most common mistake we see, because it feels like cleaning up while the credential stays live the entire time.

Notifying people is worth doing early, but keep it short: which credential, revoked at what time, and what teams should watch for. Detail can follow once the exposure is closed.

If the credential cannot be revoked immediately

Occasionally revocation is genuinely blocked: a single-key provider, a batch job mid-run, a payment integration that cannot tolerate a gap. Treat this as a timed exception rather than a reason to wait.

Narrow the exposure while you prepare: restrict the credential by IP or scope if the provider allows it, raise the alert threshold on the affected service, and put a hard time on the window. Then run the dual-key sequence and revoke.

Write the note while it is fresh

Five lines is enough: what leaked, when it was committed, when it was revoked, what the audit log showed, and one thing that would have caught it earlier. That last line is the only part that changes anything, and it is the part nobody remembers a week later.

Afterwards: make the next one shorter

The measure of an incident response is not whether the leak happened. It is the gap between the commit and the revocation. Teams that shrink that gap from months to minutes do it with automation, not with policy: a scan on every push, alerts that name the credential type, and a secret store that makes the safe path the easy one.

A scan that reports credential type alongside file and line makes the first ten minutes much faster, because you know exactly which provider console to open before you finish reading.