What is blast radius?

Blast radius is a measure of how much damage one identity, credential, or action can cause in a cloud environment. It describes the worst-case outcome if that identity is compromised, makes a mistake, or behaves unexpectedly. The smaller the blast radius, the more contained any single failure will be.

What are the four cases where blast radius matters?

Blast radius is not just a hacking scenario. It shows up across four distinct situations that teams encounter regularly.

A leaked key is the most obvious case. If a developer’s AWS access key is committed to a public repository, the blast radius equals every action that key can perform. If the key has AdministratorAccess, that means everything in the account.

An honest mistake is just as common. An engineer running a cleanup script against the wrong environment, or a misconfigured Terraform plan applied to production, causes damage proportional to the permissions attached to whoever ran it. Narrow permissions limit how far a mistake can spread.

A contractor or third-party integration represents a trusted-but-bounded identity. The blast radius question here is: if this vendor’s credentials were misused, what is the worst outcome? Broad access granted for convenience turns a vendor incident into an account-wide incident.

AI agents are the newest and fastest-growing case. An agent with production credentials can make API calls at machine speed. A human operator might notice a problem after five bad actions; an agent might have completed fifty. Keeping the blast radius small for automated identities is not optional; it is a prerequisite for using them safely.

How do you shrink blast radius?

Three categories of controls have the most practical impact.

Scoped access means writing IAM policies that specify actual resources rather than wildcards. A policy that allows s3:GetObject on arn:aws:s3:::my-bucket/* is meaningfully safer than one that allows it on *. The difference in blast radius is every S3 object in the account versus the contents of one bucket.

Short-lived credentials eliminate the window between credential issuance and credential expiry. A key that expires in one hour limits the attacker to one hour of access, with no manual revocation required. This is the core mechanism behind just-in-time access models.

Action-level guardrails block the most dangerous operations regardless of identity. Service control policies in AWS Organizations can deny actions like ec2:DeleteVpc, iam:CreateUser, or s3:DeleteBucket account-wide, so even a compromised administrator cannot reach certain outcomes. These guardrails operate outside the compromised identity and cannot be removed by it.

How does blast radius connect to least privilege?

Least privilege is the tool; blast radius is the measurement. When you apply least privilege correctly, you reduce blast radius as a consequence. An identity that can only read from one database cannot drop tables. An identity that can only write to one S3 prefix cannot touch another account’s resources.

The relationship is worth keeping distinct. Least privilege describes a design decision you make about a policy. Blast radius describes the real-world outcome if that identity goes wrong. Teams sometimes have well-intentioned least-privilege policies on paper but find the actual blast radius remains large because the policies are attached to identities that also hold older, broader policies from earlier configurations.

What is the most common mistake teams make?

Focusing entirely on perimeter security while leaving blast radius inside unchecked. The assumption is that if no one unauthorized gets in, the permissions attached to internal identities do not matter. This fails in two ways.

First, perimeters are not complete. Keys leak, sessions get hijacked, and supply chain compromises happen at the dependency level, well inside the perimeter. Second, insiders, whether human or automated, cause a significant share of cloud incidents through misconfiguration and error.

When blast radius inside the account is large, a single identity failure, from any source, becomes an account-level event.

How is blast radius different from attack surface?

Attack surface counts the entry points: how many credentials exist, how many services are exposed, how many integrations have access. Blast radius measures what each entry point can reach. Both matter, but they are not the same problem.

A system can have a very small attack surface, perhaps only one API key, and still have an enormous blast radius if that key carries administrator privileges. Conversely, a system with many identities can have a small total blast radius if each one is tightly scoped. Reducing attack surface and reducing blast radius are complementary but independent goals. Korvalis addresses blast radius directly by enforcing scoped, time-limited credentials at the point of access.