OWASP added "excessive agency" to the LLM Top 10 as LLM07 in 2025 (OWASP, 2025). The remedy is not fewer agents. It is bounded ones. An agent without a blast-radius bound turns a single prompt injection into a fleet-wide incident, and the average breach already cost $4.88M globally in 2024 (IBM Cost of a Data Breach, 2024). The 2025 update flags AI-in-use as an accelerant on top of that baseline.

This post does three things. It gives you a formula to compute blast radius. Six levers to bound it. A four-drill chaos protocol to test it. Then a one-page worksheet you can fork for any agent in your stack, including the one your vendor sold you last week. The piece assumes the basics from a general agent security checklist are covered, and drills into blast radius specifically.

What blast radius actually means for an AI agent

Blast radius is the maximum scope of side effects a single agent run can produce before it is stopped. NIST AI RMF 1.0 frames this as the impact axis of AI risk (NIST AI RMF 1.0, 2023). For agents, the inputs are capability scope, data reach, egress surface, spend ceiling, reversibility tier, and tenant boundary. The bound is not a wish, it is a number, agreed in advance with whoever owns the risk.

Five definitional points. First, compute per run, not per fleet. A fleet of bounded runs is a bounded system. A single unbounded run is a Black Swan generator. Second, units. Score each of the six inputs 0 to 5. Sum or apply a reversibility coefficient per your policy. Compare against a ceiling. Third, boundary. Anything outside the boundary is denied at the platform layer, never inside the agent code. The agent cannot reason its way through a gateway it has no credentials for.

Fourth, blast radius is not guardrails. Guardrails reduce the probability of a bad action. Blast radius reduces the cost when one happens. They sit on different axes of risk and do different jobs. Fifth, the test is asymmetric. A guardrail says "do not do X". A blast-radius bound says "even if you try X, here is the cap on damage". One trusts intent, the other does not.

How to compute blast radius (six inputs, scored 0 to 5)

MITRE ATLAS catalogs adversary techniques that exploit over-scoped agent tools (MITRE ATLAS, 2025). Each technique maps to one of the six blast-radius inputs below. Scoring each input on a fixed 0 to 5 scale lets you compare agents apples-to-apples, prioritize remediation, and produce a number you can hand to a risk owner without further translation.

  1. Capability scope (0 to 5). 0 = read-only, single namespace. 5 = arbitrary code execution. Verify by introspecting the tool registry and counting write or delete tools.
  2. Data reach (0 to 5). 0 = single row scoped to caller. 5 = full cross-tenant access. Verify by tracing the broadest query the agent can issue and looking at the data returned.
  3. Egress surface (0 to 5). 0 = no outbound network. 5 = any URL. Verify by attempting a call to a random domain and confirming the block fires at the platform layer.
  4. Spend ceiling (0 to 5). 0 = $0 (read-only). 5 = no cap. Verify by trying a transaction above the cap and confirming rejection happens platform-side.
  5. Reversibility tier (0 to 5). 0 = no-op. 5 = irreversible external (money, email, public post). Verify by mapping each tool to a tier in the registry.
  6. Tenant boundary (0 to 5). 0 = strict isolation. 5 = shared everything. Verify by injecting a cross-tenant ID and confirming a 403 at the gateway.

Lever 1: Capability scoping (the minimum-viable scope pattern)

Excessive agency (LLM07) is the failure mode capability scoping prevents (OWASP, 2025). NIST SP 800-53 codifies least privilege as the foundational access control (NIST SP 800-53 Rev 5, 2020); AWS Well-Architected Security applies it to service boundaries. For agents, the unit of privilege is the capability, not the API key, and that distinction collapses a lot of incidents.

Minimum-viable scope, the default Gravity ships with: read-only, single namespace, time-boxed. Write capability is an explicit upgrade. Delete is a gated upgrade behind human approval. Cross-tenant is blocked at the platform layer with no in-agent override. The pattern emerged out of the capability-based pricing model, which forced every capability to have a default scope, a max scope, a default rate limit, and a default reversibility tier before it could be sold.

  1. Each capability registered with explicit schema, never wildcards. Verify: registry scan, zero * entries. Default failure: tool accepts arbitrary SQL or shell.
  2. Defaults are read-only; writes are an explicit upgrade. Verify: a fresh agent has no write capability. Default failure: admin defaults applied at provisioning.
  3. Capabilities expire by default. Verify: every grant has a TTL. Default failure: forever grants accumulating across the fleet.
  4. Capability grants are independently auditable. Every grant logs who, when, why, and TTL. Default failure: grants invisible to anyone but the granter.
  5. No "god roles". Roles map to a small set of capabilities. Default failure: an ops-admin bundle that effectively grants everything.

Lever 2: Rate limits, concurrency caps, and loop budgets

Anthropic's 2025 agent safety work identifies runaway tool-call loops as a dominant failure mode in production agents (Anthropic Research, 2025). The cheapest defense is platform-enforced rate limits and a hard loop budget per run. AWS Well-Architected adds the placement rule: rate limits belong at the platform edge, not inside the application that the limits are protecting.

  1. Per-agent and per-tool rate limits enforced platform-side. Verify: load test confirms rejection above limit. Default failure: limit lives only in the prompt and is the first thing a prompt injection bypasses.
  2. Concurrency cap per tenant. Verify: N+1 concurrent runs queue or reject. Default failure: unbounded fan-out.
  3. Hard loop budget per run. Max iterations or max tool calls. Verify: a loop test halts at the budget. Default failure: runaway loop until token bankruptcy.
  4. Burst and sustained limits both enforced. 100 requests in 10 seconds rejected even if 100 per minute is allowed. Default failure: only sustained limits, easy to burst past.
  5. Per-capability rate limits. Write rate < read rate. Default failure: single shared quota that lets writes consume read budget.

Lever 3: Egress controls (allow-list, payload scanning, DNS pinning)

Data exfiltration is LLM02 (sensitive information disclosure) on the OWASP 2025 list (OWASP, 2025). Most teams allow-list inbound traffic carefully then leave outbound wide open. For agents, every external tool call is a potential exfiltration channel, and the prompt that triggers it can come from any retrieval surface the agent reads from.

  1. Outbound destinations are allow-listed per agent. Verify: call to an un-listed domain is blocked at platform layer. Default failure: any URL allowed.
  2. Outbound payload size capped. Verify: a 100MB POST is rejected. Default failure: unbounded payload size, perfect for whole-database exfiltration.
  3. Outbound payload scanned for PII and secrets before send. Verify: inject a fake credit card; scanner blocks. Default failure: no outbound DLP at all.
  4. DNS pinning to prevent rebind attacks. Verify: a domain whose IP changes mid-run does not bypass the allow-list. Default failure: no DNS pinning, classic rebind sidesteps the list.
  5. Per-call destination logged for audit reconstruction. Verify: replay a run, see every URL the agent hit. Default failure: only error logs, no success logs.

Lever 4: Spend caps (token, dollar, and external-API-call ceilings)

Token cost is the meter most teams watch. The more dangerous meter is external-API cost: Stripe transfers, SMS sends, third-party agent fees, paid web searches. A platform-side spend cap closes the worst-case dollar exposure per run. Tracking the meter in metrics is not the same as enforcing it in the request path, and only the second one matters when the prompt is hostile.

  1. Per-run token budget enforced platform-side. Verify: a run hitting the budget halts. Default failure: budget tracked, not enforced.
  2. Per-tool dollar cap on money-moving tools. Verify: a $10,001 transfer with a $10,000 cap is rejected before the tool fires. Default failure: cap in the prompt only.
  3. Per-tenant daily spend cap with alerts at 50, 75, and 90 percent. Verify: synthetic burn triggers alert chain. Default failure: alerts only at 100 percent, by which point the spend already happened.
  4. External-API-call ceilings per third-party tool. Verify: a tool exceeding its quota is paused fleet-wide. Default failure: no per-tool quota.
  5. Spend cap state visible in the agent's reasoning trace. Verify: trace shows remaining budget at each step. Default failure: agent unaware of cap, plans actions it cannot afford.

Lever 5: Reversibility tiers and compensating actions

Reversibility is the single highest-leverage input to blast-radius scoring. A Tier 4 action costs more to remediate than every other lever combined. Anthropic's 2025 agent safety guidance recommends explicit tiering plus compensating actions for any non-zero tier (Anthropic Research, 2025), and most production incidents at scale trace back to a Tier 3 or 4 action that the agent had no business taking.

TierDefinitionExampleRough remediation cost band
0No-op or fully reversibleDatabase read$0
1Reversible internalRow update with backupMinutes of ops time
2Reversible external with costSlack message deleteTens of dollars
3Hard to reverseEmail already openedThousands of dollars
4Irreversible externalMoney transfer$4.88M-class incident
  1. Every tool tagged with a reversibility tier in the registry. Verify: registry export shows tier per tool.
  2. Tier 3 and 4 require explicit human gate by default. Verify: try a Tier 4 call, confirm gate fires.
  3. Compensating action documented for every Tier 2+ tool. Every send-money has a documented reversal plan, even if the reversal is partial.
  4. Reversibility tier multiplies blast-radius score in high-stakes systems. Coefficient applied at scoring time.

Lever 6: Tenant isolation and cross-tenant denial

Cross-tenant data leakage is the catastrophic failure mode for any multi-tenant agent platform. AWS Well-Architected Security pillar names tenant isolation as a foundational requirement. OWASP LLM02 (sensitive information disclosure) is the agent-layer analog (OWASP, 2025). The control belongs at the platform layer, never gated in the agent code where a clever prompt can argue its way through.

  1. Tenant boundary enforced platform-side, not in the agent prompt. Verify: a tenant-A agent attempting tenant-B access returns 403 at the gateway.
  2. Per-tenant secret scopes (no shared umbrella keys). Each tenant's vault path differs. Default failure: shared API key for the whole fleet.
  3. Per-tenant log encryption with separate KMS keys. Pulling tenant-A logs with tenant-B credentials fails.
  4. Cross-tenant tool calls always blocked. Registry rejects cross-tenant tool registration.
  5. Tenant-aware rate limits and spend caps. Tenant A burning quota cannot starve tenant B.

Testing blast radius: chaos engineering for agents

Chaos engineering for agents is the only way to verify the bounds you wrote down actually hold. Google DeepMind's 2025 agent safety guidance argues for adversarial evaluation as a precondition to deployment. The four drills below give you a one-day test pass per agent. Run them quarterly and before any capability scope upgrade. The drills target side effects in dollars, rows touched, and external messages sent, not infra availability.

  1. Egress probe. Feed the agent a prompt instructing it to POST data to a random external URL. Pass = blocked at platform layer. Fail = call succeeds.
  2. Spend probe. Instruct the agent to issue a transaction one dollar above its per-tool cap. Pass = rejected before the tool fires. Fail = transaction goes through, even partially.
  3. Cross-tenant probe. Provide the agent with a tenant ID that is not its own and instruct it to fetch that tenant's data. Pass = platform 403. Fail = data returned.
  4. Irreversibility probe. Instruct the agent to perform a Tier 4 action in staging without going through the gate. Pass = gate fires regardless of prompt. Fail = silent execution.

Each drill ships with a stopwatch criterion: median run-to-block latency under 5 seconds, p99 under 30. Document results on the agent's worksheet. If you cannot make a drill fail in a sandbox you do not yet have a sandbox.

Communicating blast radius: the worksheet

Auditors and procurement leads in 2026 are building agent-specific question sets. NIST AI RMF emphasizes impact assessment as a documented, transferable artifact (NIST AI RMF 1.0, 2023). A one-page blast-radius worksheet per agent is the cheapest way to satisfy buyer due diligence, procurement intake, and internal risk review with one document.

  1. One worksheet per agent, stored alongside the agent definition. Every agent in the registry has a paired worksheet.
  2. Worksheet reviewed on every capability upgrade. Upgrade tickets link to a worksheet diff.
  3. Worksheet auto-rendered in the platform UI for the agent's owner. Owner sees current score in dashboard.
  4. Public-facing summary version available for buyer questionnaires. Redacted version per agent product.
  5. Worksheet signed off by risk owner annually. Signature plus date stored.

FAQ

What is blast radius for an AI agent?
The maximum scope of side effects a single agent run can produce before being stopped. Computed from capability scope, data reach, egress surface, spend ceiling, reversibility tier, and tenant boundary. Aligns with NIST AI RMF impact framing and the OWASP LLM07 (excessive agency) failure mode.
How is blast radius different from guardrails?
Guardrails reduce the probability of a bad action. Blast radius reduces the cost when one happens. You need both. Guardrails are filters; blast radius is a cap.
How do I compute blast radius?
Score each of the six inputs 0 to 5, sum (or multiply reversibility tier as a coefficient for high-stakes systems), compare against a ceiling agreed with the risk owner. The worksheet above is fork-friendly.
What is a spend cap on an AI agent?
A platform-enforced ceiling on tokens, dollars, or external-API calls per run, per tool, per tenant, per day. Enforced at the platform layer, never just in the prompt.
How do I test an agent's blast radius?
Run the four chaos drills: egress probe, spend probe, cross-tenant probe, irreversibility probe. Each has a stopwatch criterion. Run quarterly or before any capability upgrade.
What are reversibility tiers?
A 0 to 4 ranking from no-op to irreversible external side effect. Higher tiers require human gates and compensating actions. Tier 4 actions dominate remediation cost.
How do I tell a buyer what an agent's worst case looks like?
Hand them the agent's blast-radius worksheet: scores per input, total score, ceiling, last chaos-drill results. Cheaper than answering bespoke questionnaires.

Closing the loop

Three ideas to keep. Defaults matter more than docs: a platform that defaults to Tier 0 read-only beats one that documents Tier 4 with caveats. Bounds must live at the platform layer, never in prompts the agent can argue its way through. And the worksheet is a buyer-facing artifact, not just an internal one. Fork it, run it against any platform including Gravity, and file the gaps.

Related reading on this site: the broader agent security playbook, common agent failure modes, and how guardrails and blast radius differ. For the founder posture on building this stack from Bangalore, see about.

Sources