Before you rotate anything, decide what you’re trying to learn.

A secret has leaked: an API key in a public repo, a token in a client-side bundle, a database password in a log shipped to a third party. The instinct, drilled into everyone, is to rotate it immediately. That instinct is mostly right and occasionally expensive. Rotate too fast, with no record of what you did or what the key could reach, and you’ve closed the door without ever checking whether someone was already inside. This guide is about the thirty minutes that decide which of those two stories you get to tell.

What actually happened, in the order it matters

The panic version of a leak treats every exposed credential as equally urgent. It isn’t. Three questions sort the real emergencies from the paperwork, and they’re worth answering before your hands are on the rotate button.

What can this secret do? A read-only key scoped to one bucket is a different event from a root credential that can mint more credentials. Write down the blast radius in plain language: what it reads, what it writes, what it can escalate to. If you don’t know, that unknown is itself the finding. The leak just told you that you have a credential nobody can fully account for.

How long was it exposed, and where? “Committed to a public repo” is not one fact. It’s the commit time, the time the platform’s secret-scanning first saw it, and the time you saw it. Public repos are indexed and scraped within minutes, not days. Assume exposure started at commit, not at discovery. A key that sat in a private log for an hour is a different risk from one that was searchable on the open internet overnight.

Was it used? This is the question people skip because it’s slower than rotating, and it’s the one that separates a hygiene event from an incident. Before you invalidate the key, pull its usage: the calls it made, from which addresses, in what pattern. You are looking for the shape of activity you can’t explain: a new source, an odd hour, a burst of reads it never normally does.

The trade-off nobody names

Here is the tension the runbooks gloss over: rotating the secret protects you going forward, and it can destroy the evidence that tells you whether you were already compromised. The moment you invalidate a key, some providers stop showing you its recent activity, or the attacker’s next call simply fails and you lose the thread.

You don’t have to choose blind. The move is to capture before you cut. Export the access logs for that credential first, even a rough copy-paste is enough, then rotate. Thirty seconds of preservation buys you the ability to answer “was it used” after the key is already dead. The order is capture, then rotate, then investigate. Reverse the first two only when the blast radius is so large that every additional second of validity outweighs the evidence.

Doing the rotation so it actually holds

Rotation fails quietly more often than it fails loudly. A few things worth checking before you call it done:

• Find every copy. A secret lives in more places than the one that leaked: CI variables, a teammate’s .env, a second service that reuses it, a cached build. Rotating one and missing three means you’ve had an outage and kept the exposure.
• Confirm the old one is dead. Don’t assume revocation took. Make a call with the old credential and watch it fail. “I rotated it” and “the old one no longer works” are different claims, and only the second one is true security.
• Watch for the fallout. A hard rotation breaks things that quietly depended on the old value. Expect a few, and have someone watching error rates while you do it. A broken deploy at hour one is a normal cost; a silent one at hour six is a second incident.

What good looks like afterward

The event isn’t closed when the key is rotated. It’s closed when you can answer three things in writing: what the secret could reach, whether anything used it that shouldn’t have, and how it got exposed in the first place. That last one is where the real fix lives. A key in a repo is rarely a discipline problem. It’s usually a missing guardrail, a secret that should have been a short-lived token, a scanning gate that ran after the push instead of before it.

The patient version of this work is unglamorous: fewer long-lived secrets, tighter scopes, scanning that blocks the commit rather than emailing you about it. None of that helps in the first thirty minutes. But the first thirty minutes go a great deal better when there’s less to leak, and when the thing that leaks can’t do much.

The one habit to keep

Treat every leaked secret as a question before you treat it as a fire. Capture what it did, then kill it, then learn from how it got out. Most exposed credentials were never used by anyone but you, and you only get to know that if you look before you rotate.