Sources#
Summary#
Blast radius measures the potential damage if something goes wrong with an agent. A read-only-to-one-database agent has a small blast radius; an agent with administrative access to cloud infrastructure has an enormous one. In Zero Trust for AI Agents it is the central unit of the "assume breach" principle: security investment should match exposure, and the design-for-breach posture means assuming every agent's blast radius will eventually be tested.
Why it's the right unit#
Zero Trust does not promise to prevent compromise — it promises to contain it. Blast radius reframes the security question from "can we keep attackers out?" (a losing perimeter game under AI-Accelerated Offense) to "when an agent is compromised, how much can it reach?" Every other control in the framework — Least Agency, identity, isolation — is ultimately justified by how much it shrinks this number.
Containment mechanisms (resource boundaries)#
The framework's primary blast-radius control is identity-based isolation, not network segmentation:
- Identity-based isolation (Foundation) — every agent workload carries its own cryptographic identity, and each service accepts connections only from explicitly named callers. Network segmentation is a backstop, not the primary boundary — an attacker who reaches a segment boundary will pivot through it if services accept any caller from that network. "Enforce isolation at the receiving end."
- Sandboxed execution (Enterprise) — containers with restricted capabilities, runtimes like gVisor for syscall filtering, limited mounts/network. Treated as mandatory, not aspirational, for any agent processing untrusted input (web content, documents).
- Hardware isolation (Advanced) — AMD SEV / Intel TDX, microVMs, attestation; not even the host OS can inspect or tamper with the workload.
Complementary credential-side containment (Agent Identity and Authentication): per-agent credentials and credential isolation mean a single stolen secret doesn't grant the combined access of every agent sharing it.
Compartmentalization as deliberate design#
Phase 3 of the workflow makes blast-radius assessment an explicit step: with approved actions, prohibited actions, escalation triggers, and scope limits defined, identify what could go wrong if the agent were compromised. The framework recommends breaking an agent's functions into multiple agents with distinct identities so attackers must compromise more of them to reach more resources — but only if each gets unique credentials (shared credentials defeat the compartmentalization).
The impossible-vs-tedious link#
Blast-radius assessment must be run through the Impossible, Not Tedious (Design Test): "If your containment plan relies on friction — the attacker would have to make a lot of requests, or bypass several rate limits — assume it will fail." A blast radius that is only inconvenient to traverse is not contained; if the residual risk is unacceptable, tighten the controls until traversal is impossible, not merely tedious.
Connections#
- Zero Trust for AI Agents — blast radius is the unit the "assume breach" principle contains (hub)
- Least Agency — the input control; constraining agency is how you shrink blast radius
- Agent Identity and Authentication — identity-based isolation and per-agent credentials are the primary blast-radius controls
- Impossible, Not Tedious (Design Test) — the test a containment plan must pass: impossible traversal, not merely tedious
- Claude Code Best Practices — sandboxed execution + write-access restrictions as a reference containment implementation
- Autonomous Defense — the same blast-radius containment applied inward on defensive (Agentic SOAR) agents, which are themselves high-value targets
Open Questions#
- The framework prefers identity-based isolation over network segmentation, but most enterprises have heavy segmentation investment. What's the migration path, and does dual-running create new gaps?
- Multi-agent compartmentalization increases the number of identities to manage; at what point does identity-management overhead create its own attack surface?
Sources#
- Zero Trust for AI Agents — blast radius defined in Part I; resource boundaries in Part III; Phase 3 blast-radius assessment in Part IV
Cited by 7
- Agent Identity and Authentication
The foundation control for agentic Zero Trust: cryptographically-rooted per-agent identity (→X.509→hardware attestation…
- Autonomous Defense
Running security operations at the speed of AI-accelerated threats: put a model at the front of the alert queue, automa…
- Claude Code
Anthropic's agentic coding product; created by Boris Cherny late 2024; TypeScript/React; CLI/desktop/web/mobile/IDE sur…
- Impossible, Not Tedious (Design Test)
Zero Trust design test for agentic security: does a control make the attack impossible, or just tedious? Friction-only…
- Least Agency
OWASP term extending least privilege to agents: constrain not just what an agent can access but what each tool can do,…
- MOC — AI Engineering & Agent Tooling
<!-- BEGIN GENERATED: moc -->
- Zero Trust for AI Agents
Anthropic's security framework for deploying autonomous agents: trust nothing / verify everything / assume breach, appl…
Related articles
- Zero Trust for AI Agents
Anthropic's security framework for deploying autonomous agents: trust nothing / verify everything / assume breach, appl…
- Least Agency
OWASP term extending least privilege to agents: constrain not just what an agent can access but what each tool can do,…
- Agent Identity and Authentication
The foundation control for agentic Zero Trust: cryptographically-rooted per-agent identity (→X.509→hardware attestation…
- Autonomous Defense
Running security operations at the speed of AI-accelerated threats: put a model at the front of the alert queue, automa…
- MCP and Computer Use
Anthropic's two complementary connector mechanisms: MCP for structured programmatic access (Salesforce/Drive/Gmail/Slac…
