Blast radius

Why is the important question about a compromised credential not what it unlocks but how far it reaches?

Two credentials leak. The first is an administrator key — full powers — for a throwaway namespace that holds one test database and expires in an hour. The second is a read-only token, the humblest thing on the list, but it is the same token in every environment, it never expires, and one of the things it can read is the store where other services keep their own keys.

Which leak is worse? The instinct trained into us by permission lists says the first, because administrator is the bigger word. Yet almost everyone who has handled a real incident says the second. If the permission label is the wrong guide, what is the right one?

Start by asking what a permission list actually describes. It describes one hop: the set of operations this credential may perform on the resources it names. That is a genuine fact, and it is also where the analysis usually stops.

But an attacker does not stop there. Having reached a resource, they ask what that resource can reach. A machine you can run code on holds its own environment variables, its own service account, its own network position. So the real quantity is not the permission set but its transitive closure — everything reachable by following credentials found along the way. That movement is called lateral movement, and it is why a modest foothold becomes an incident.

Notice that the closure depends on facts nowhere in the permission list. Whether the reachable machine happens to store another key. Whether the network lets it talk to the payment service. Whether staging and production share an identity provider. None of that appears in the grant, and all of it determines the reach.

Now add a second dimension people often forget. A credential has a lifetime, and lifetime multiplies reach in time. A leaked token valid for five minutes reaches only what an attacker can touch in five minutes — and if the attacker found it in an archived log a year later, it reaches nothing at all. The same permissions on a token that never expires reach every state the system passes through for as long as it exists. This is why short-lived credentials are so disproportionately effective: they do not reduce what a credential can do, only how long the doing lasts, and that turns out to be most of the exposure.

There is a third dimension, and it is the one that made the read-only token worse than the administrator key: breadth of identical deployment. A secret that is the same in three environments has three times the chance of leaking and, once leaked, reaches all three. A secret unique per environment reaches one. The permission set is unchanged in both cases.

So put the three together and you have something better than a label. Reach is roughly: what this credential touches directly, times what those things can reach onward, times how long the credential stays valid, times how many places share it. Any of those factors being large makes the others matter less. That is what makes blast radius the right question — it is a product, and a permission list only tells you one term of it.

Does this mean least privilege is wrong? Not at all — but it explains why least privilege alone underperforms expectations. Trimming permissions shrinks one factor. Segmentation shrinks the second, expiry the third, per-environment secrets the fourth. Teams that only do the first are optimising the term that is easiest to see.

One more move, because it matters for automated systems in particular. An assistant acting on your behalf typically holds a credential for the span of a task it plans itself. The reach question there is not "what did we authorise" but "what is reachable from what we authorised, over a task whose steps we never enumerated". That is why scoping such credentials to one task, one resource and a short window does more for safety than tightening the verb list.

Three refinements.

The first is that read-only is not a synonym for safe. Reading is how an attacker discovers everything else, and many stored secrets are readable objects: environment files, configuration stores, backups, logs that captured a header they should not have. A read-only credential over a secret store has a radius limited only by what those secrets unlock.

The second is that revocation belongs in the calculation. Reach ends when the credential stops working, so the practical question is not only how long the token is valid but how long it takes you to notice and how long to rotate. A credential you can kill in seconds has a smaller radius than an identical one embedded in a firmware image, even though their permissions match exactly. Detection latency is part of the radius, uncomfortable as that is to measure.

The third is a caution about the metaphor. A blast radius is a circle around a point, suggesting reach falls off smoothly with distance. It does not. Reach in a network is graph-shaped and lumpy: two hops through an ordinary service may lead nowhere, while one hop into an identity provider leads everywhere. Look for the hubs, not the distance.

• How audience-bound tokens close the confused-deputy path, where a legitimate service is persuaded to use its own credentials on an attacker's behalf.
• How to scope a credential to a single agent task when the steps of that task are not known in advance.

Every term the collection defines is gathered in the glossary.