Blast radius: how far should one leaked AWS credential reach?

Assume the credential leaks. Now what?

Most cloud security work is spent trying to stop credentials escaping. That work matters, and it will also eventually fail. A laptop gets stolen, a token lands in a log, a dependency turns hostile, a contractor keeps a key.

So the more useful design question is the second one. When a credential does escape, how far does it get before something stops it? That distance is your blast radius, and unlike the probability of a leak, it is something you fully control.

Blast radius is a property of boundaries, not of policies

A policy says what an identity may do. A boundary says what is reachable at all. The difference matters, because policies are edited constantly by people under deadline pressure, and boundaries are not.

On AWS, four boundaries do most of the work.

The account boundary

This is the strongest one, and the most underused. Separate accounts for production, for staging, for your security tooling and for your logs mean a credential from one cannot enumerate the others. Organisation-level controls then set limits that no policy inside a member account can widen, which is the part that survives the Friday deployment.

Teams resist multiple accounts because it sounds like more administration. In practice it is less, because the questions get simpler. “Can staging reach production data?” stops being an analysis and becomes a yes or no.

The network boundary

A flat network means a foothold anywhere is a foothold everywhere. Private subnets, security groups written as allow-lists rather than as convenience, and endpoints that keep service traffic off the public internet all shorten the distance an attacker can travel.

The test is simple to state. From a compromised workload, what else answers on the network? If the answer is “most things”, the network is doing no work for you.

The data boundary

Encryption at rest is table stakes and proves little on its own, because the workload usually holds the key it needs. The question worth asking is which identities can decrypt what. Separate keys per data class, with key policies that name who may use them, turn a single stolen credential into access to one dataset rather than all of them.

The time boundary

A long-lived access key is a permanent liability. A short-lived session credential is a liability with an expiry date. Moving from the first to the second — roles assumed through your identity provider, instance and workload identity instead of stored keys — means a leaked credential is often already useless by the time anyone could abuse it.

This is usually the single highest-value change available to a team that has not made it yet.

The exercise that actually finds the gaps

Reading your own architecture will not reveal the blast radius, because you will read it the way you intended it. Run the exercise instead.

Pick one workload. Assume its credential is in hostile hands. Then, on paper and with your team in the room, work outward.

• What can this identity read, and does any of it contain another credential?

• What can it write, and could a write become code execution somewhere else?

• What other identities can it assume, and what can those reach?

• What answers on the network from where it runs?

• Which of the steps above would appear in a log that a human actually reads?

That last question is usually where the room goes quiet. Teams often find that an attacker could traverse three or four hops and that every hop was logged perfectly, into a bucket nothing reads and nothing alerts on.

Chained privilege is the one people miss

Single permissions look harmless in isolation. Chains do the damage.

A role that can write to a deployment bucket may not look like an administrator. If a pipeline reads that bucket and runs what it finds with elevated permissions, it is one. A role that can modify a function's configuration may look minor, until you notice the function runs with permissions the role does not have.

This is why generated policies and permission reviews are not enough on their own. Somebody has to ask the follow-up question: once an attacker has this, what does it let them get next? That is an adversarial question, and it is best answered by someone actively trying to find the chain rather than reading a list.

Containment is not an admission of failure

There is a quiet reluctance to design for containment, because it feels like conceding that prevention will fail. It will. Every organisation that has been breached had a prevention strategy.

The teams that come out of an incident well are not the ones that were never breached. They are the ones where the breach reached one account, one dataset and one afternoon, because the boundaries held and somebody got an alert that woke them.

Design for the second question. The first one is not entirely in your hands.