Leaked Credential Blast Radius: Know the Reach Before You Revoke

A credential lands in a repository. The first instinct is to rotate it. The better first question is what it can reach.

The leaked credential blast radius is the set of accounts, resources and systems a key can touch right now, under the permissions it actually holds, until it stops working. That set decides how urgent the incident is, who needs to be involved, and what breaks when you pull the key.

Most teams skip this step because they cannot answer it quickly. Permissions live in the cloud provider, consumers live in deployment configuration, and the token sits in git history. This post is about closing that gap: how to map reach, how to choose between revoke and replace, and how to read a revoke outcome so nobody is guessing.

What a leaked credential blast radius includes

Blast radius is not one number. It is five facts about the credential, and each one changes the response.

• Identity. Who the key acts as: an IAM user, a service account, a bot user in a chat workspace, a personal token tied to a human.
• Permissions. The policies attached to that identity, the scopes on the token, and any roles it can assume from there.
• Resources. What those permissions resolve to in practice: buckets, databases, repositories, secrets stores, model endpoints, billing.
• Consumers. Which services use the key today, in which environments, and how exposed those services are.
• Time. When the credential expires. A token with twenty minutes left is a different incident from a key that never expires.

Two findings with the same detector label can have blast radii that differ by orders of magnitude. One is a read-only key on a development bucket. The other is an administrator in the production account. The scanner's label does not tell you which; the identity and its permissions do.

Why "rotate it" is the wrong first question

Deleting the line from the file does nothing. The commit still exists, every clone still has it, and a fork may have it too. Containment happens at the provider, where the credential is made to stop working.

Rotating without a reach map produces two failure modes. You under-respond: a key with administrative access to production gets the same thirty-day treatment as a test token. Or you over-respond: you pull a key that three production services share, at two in the morning, and turn a leak into an outage.

Reach answers both. It tells you how fast to act and what will stop working when you act. It also scopes the investigation. If the key can reach four buckets and one queue, the audit log review covers those five resources, not the whole account.

So the order is: confirm it is live, map what it reaches, then decide how to contain it. Rotation is the second question, not the first.

Mapping the reach of a leaked key

Work through the questions in sequence. Each one narrows or widens the incident.

1. Is it live? Test the credential with a read-only call to the provider. A dead key has no blast radius today. It is still a hygiene finding, but it is not an incident.
2. Who does it act as? The provider's answer to the live check usually names the identity: an ARN, a user login, a team, a project. Record it. Everything else hangs off this.
3. What can that identity do? Pull the attached policies, group memberships and token scopes. Read them for effect, not for intent. A policy named "read-only" that includes a write action is a write policy.
4. Which resources does that map to, and which do you not monitor? Resolve the permissions against the inventory you have. Resources that fall outside your inventory are the ones to flag, not the ones to ignore.
5. Who uses it, and when does it expire? List the consumers by environment and exposure. Note the expiry. Both feed the containment decision.

Policy variables: read them exactly

Cloud policies often use variables that resolve at request time. The common AWS example is a self-service policy that lets a user manage their own access keys, written as "Resource": "arn:aws:iam::123456789012:user/${aws:username}". Read literally, that looks like every user. Resolved for the leaked key's identity, it is one user's own ARN.

Some variables cannot be resolved offline, because they depend on the request's source address, tags or session. Treat those as unknown, and never let an unresolved variable make a grant look wider than the evidence supports. "Unknown" is a valid answer in a reach map. "Probably fine" is not.

Revoke, replace, or retire: choosing the containment move

Once reach is mapped, there are three honest responses. The choice depends on what is live, what is exposed and what depends on the key.

• Containment-first. Deactivate the key now and accept the risk of breaking a consumer. This is the right call when the credential is confirmed live, the repository is or was public, or the identity holds administrative access in a production account.
• Migration-first. Issue the replacement credential, move the consumers, then deactivate the old key. This is the right call when the consumers are production-tier and the reach is bounded and non-administrative. The migration window is measured in hours, not sprints.
• Retirement. No consumer uses the key. Delete it and close the identity if nothing else depends on it.

For AWS access keys there is a useful middle step. AWS lets you set a key to Inactive before you delete it, and an inactive key can be reactivated. Deactivate first, watch for anything that breaks, then delete. From the CLI it is one command:

aws iam update-access-key --user-name deploy-bot --access-key-id AKIAEXAMPLEKEYID --status Inactive

Whatever the provider, the replacement credential should be narrower than the one it replaces. The OWASP Secrets Management Cheat Sheet covers the practices that keep blast radius small by design: least-privilege scopes, short lifetimes, and rotation as a routine rather than an emergency.

Reading a revoke outcome

A revoke is not finished when the API call returns. Provider responses are inconsistent.

A success status can precede eventual consistency across regions. A not-found response may mean the key was already deleted, or that you targeted the wrong account. A rate limit tells you nothing about the key at all.

The only reliable confirmation is to test the credential again, read-only, and get a rejection. If it still authenticates, the revoke did not happen, whatever the first response said.

Every revoke needs to end in one of three final states, and "pending" is not one of them:

• Deactivated and confirmed. The provider rejected the credential on a fresh check.
• Failed, with a reason. Permission denied, wrong account, provider error. The next action is named.
• Still live. The provider gave an unclear answer and the check found the key working. Revoke again.

Then update the record. The finding's status, the owner's next step and the remediation deadline all need to change the moment the credential is dead. If the queue still says "rotate now" for a key that no longer works, people stop trusting the queue. Keep the audit trail too: who revoked, when, and what the provider answered.

A leaked credential blast radius checklist

For the next credential that lands in git, this is the order of operations.

1. Validate it live with a read-only call. Dead keys go to the hygiene backlog.
2. Identify the principal the key acts as. Record the account and the identity.
3. Resolve the permissions to concrete resources. Resolve policy variables for this identity, and mark the ones you cannot resolve as unknown.
4. List the consumers by environment and exposure, and note the expiry.
5. Decide: containment-first, migration-first or retirement. Write the reason down.
6. Deactivate before you delete where the provider allows it.
7. Re-test the credential and record the final state.
8. Update the finding, the owner and the deadline. Close the ticket on evidence, not on effort.
9. Review the access logs for the resources inside the reach map, for the window since first exposure.
10. Replace the credential with a narrower, shorter-lived one.

This is the same practice whether the key is an AWS access key, a GitHub token or a model-hosting token. The provider changes the commands. The order does not change.

How Heeler maps a leaked credential blast radius

Heeler's secrets detection and validation scans every branch and the full commit history, then runs a safe, read-only check against the provider to confirm whether each credential still works. A confirmed-live credential is re-tested at least every four hours, and a push to the default branch re-tests every credential in the repository.

Each secret finding carries a recommendation: Rotate now, Rotate, Investigate now or Investigate. The recommendation is built from live validation, the cloud identity and blast radius Heeler can establish, and where the secret sits. Public exposure, potential administrative access in a production-equivalent account, and use by an exposed production consumer each escalate the recommendation, and the recommendation sets the Secrets SLO deadline: three days for Rotate now by default, and thirty for Rotate.

The secret drawer shows every resource a leaked credential can reach. The Overview tab has a reach card with the access summary, the number of resources outside Heeler, who the credential acts as, when it expires and its strongest resources. The Evidence & decision tab groups resources by owner, marks each as monitored by Heeler or outside Heeler, and shows the token's expiry, scopes and account type with a reason and risk badge per resource. Checks that found nothing or could not run say so.

For a leaked AWS key, reach resolves IAM policy variables such as ${aws:username} to the user's own ARN, and a variable that cannot be resolved is marked "Depends on request context" and never widens a grant. Potential administrative access comes from policy analysis and is presented as evidence, not as proof of access.

How Heeler reports a revoke outcome

Revoke is available for Hugging Face tokens and for credentials on verified rules. The confirm dialog shows what will be deactivated, the account and user, known users, last use, and a warning that applications using the key will stop working.

Every revoke reaches a final state within about 90 seconds, with a next action, and validation decides an unclear provider answer, so a credential that is still live is offered Revoke again. After a revoke, the finding's recommendation, credential status, next steps and SLO update immediately. For credential types with no live validator, an administrator can mark the credential as rotated; that mark is cleared if a later check finds the credential working.

The reach map draws on the Context Engine, which ties the credential to its cloud identity, its consumers and their exposure. For the triage step that comes before reach, see Secret Scanning Triage: Not Every Leaked Key Is an Incident.

FAQ

What is a leaked credential blast radius?

A leaked credential blast radius is the set of accounts, resources and systems a leaked key can reach right now, under the permissions its identity holds, until it expires or is revoked. It is defined by the identity, its permissions, the resources they resolve to, the consumers that use the key, and the time left on it.

Should I remove the secret from git history before rotating it?

No. Revoke at the provider first; history rewriting is hygiene, not containment. Every clone and fork made before the rewrite still holds the commit, so the credential stays exposed until it stops working.

Is deactivating an AWS access key the same as deleting it?

No. An inactive AWS access key stops authenticating but can be reactivated, while a deleted key is gone. Deactivate first to see what breaks, then delete once the replacement is in place.

How do I know a revoke actually worked?

Test the credential again with a read-only call and confirm the provider rejects it. A success response from the revoke API is a claim; a failed authentication on a fresh check is evidence.

Does a credential that fails validation still need action?

Yes, but not as an incident. A dead key has no blast radius today, so it belongs in the hygiene backlog: remove it from the code, check why it was committed, and make sure the replacement is stored properly.

Heeler shows what a leaked credential can reach before you act, and reports a clear outcome when you revoke it. See the reach map and the revoke flow on your own repositories. Get a demo