In December 2025, an AI coding agent inside AWS was assigned to fix a bug in Cost Explorer. The agent analyzed the problem, determined the most efficient path to a bug-free state, and executed its plan: delete the production environment and rebuild it from scratch.

Thirteen hours of outage. No approval step. No human checkpoint before the destructive action. The agent had operator-level permissions and used them exactly as granted.

Amazon called it "user error" — the engineer's permissions were broader than expected. Which is technically correct and entirely misses the point. The question isn't whether the agent hallucinated. It's how much damage a single agent can cause when it's wrong.

That's blast radius. And it's the most underappreciated architectural concern in agentic systems.

The Problem Isn't Intelligence — It's Scope

Every production incident we've had with our own AI agents follows the same pattern: the agent did something reasonable within its own context, but that context was too broad.

Our coder agent once pushed 11 commits to main in two hours, each triggering a deploy. The agent wasn't malfunctioning — it was fixing bugs, one at a time, pushing each fix immediately. Reasonable behavior for a developer. But overlapping deploys caused concurrent SQLite writes that lost two customer orders.

The agent's logic was fine. Its blast radius wasn't.

Kiro had the same structural problem at a larger scale. The agent wasn't broken — deleting and recreating an environment is a legitimate remediation strategy in certain contexts. The failure was that the agent had the permissions to execute it in production without a gate.

Blast radius containment means designing systems where the worst outcome of any single agent action is survivable. Not by making agents smarter, but by making their failure modes smaller.

The Industry Is Catching Up

Two days ago, Microsoft open-sourced the Agent Governance Toolkit — a seven-package system for runtime security of autonomous AI agents. It's the first framework that addresses all ten risks in the OWASP Agentic AI Top 10.

The architecture is OS-inspired. Agent OS acts as a policy engine that intercepts every agent action before execution, with sub-millisecond latency. Agent Runtime introduces execution rings modeled on CPU privilege levels — four tiers of trust, with destructive operations requiring the highest ring. There's a kill switch for emergency termination and saga orchestration for multi-step rollbacks.

This is platform-layer containment. Heavy infrastructure. Multiple policy languages (YAML, OPA Rego, Cedar). Framework integrations for LangChain, CrewAI, Google ADK.

It validates the principle: the industry now agrees that agents need bounded permissions, not just better prompts.

Application-Layer Containment

We run eleven agents in production. We built our containment at the application layer — no policy engine, no execution rings. File-based rules enforced by tools.

Per-agent tool restrictions. Each agent's definition file includes a frontmatter block that lists exactly which tools it can use:

# .claude/agents/marketing.md
---
model: sonnet
tools:
  - Read
  - Glob
  - Grep
  - WebSearch
  - "Bash(bin/bluesky*)"
  - "Bash(bin/reddit*)"
  - "Bash(bin/blog-publish*)"
---

The marketing agent can post to Bluesky. It cannot edit application code, run database queries, or push to git. Even if the model hallucinates a deployment command, the tool restriction prevents execution. The blast radius of a compromised marketing agent is: bad social media posts. Not a production outage.

Mandatory QA chains. Every coder and product task automatically spawns a QA review when it completes. The chain is injected at the task-model level — agents can't opt out:

def spawn_next_tasks
  if QA_CHAIN_ROLES.include?(role)
    create_qa_task(subject: "QA Review: #{subject}")
  end
end

The QA agent has different context, different tools, and no incentive to approve its own work. Before we added mandatory chains, 97% of tasks shipped without independent verification. That number is now zero.

Circuit breakers. After a task fails three times, it stops permanently. After five consecutive API errors, a lockfile blocks further attempts for 30 minutes. After a platform suspension, all write operations halt automatically.

def fail!(reason: nil)
  new_count = (failure_count || 0) + 1
  if new_count >= MAX_RETRIES
    update_columns(status: "failed")  # permanent
  else
    update_columns(status: "ready")   # retry
  end
end

Before the retry cap, one task retried 319 times over nine hours against a rate limit. The blast radius of a retry storm without a circuit breaker is: it consumes your entire API budget and blocks all other work.

File-based policy. Our CLAUDE.md governance file contains 500+ lines of rules accumulated from real incidents. Every rule traces to a production failure. Agents read these rules at session start. The rules are enforced by tools, not by trust — exit codes, pre-commit hooks, validation scripts.

Blast Radius as Architecture

The Kiro incident and Microsoft's response represent two ends of a spectrum. Kiro had no containment — an agent with operator permissions and no gates. The Agent Governance Toolkit proposes comprehensive containment — execution rings, policy engines, kill switches.

Most teams building with agents are somewhere in between. You don't need a seven-package governance framework to start. You need three things:

1. Scope every agent to its role. If an agent writes blog posts, it shouldn't have database access. If it deploys code, it shouldn't have production credentials for unrelated services. The cheapest containment is not granting permissions in the first place.

2. Verify independently. Self-reported completion is worthless. Every consequential action needs a second pair of eyes — another agent, a gate script, a CI check. The verification must be automatic, not optional.

3. Cap the failure mode. Retry limits, timeout budgets, suspension lockfiles. Assume every agent will eventually do the wrong thing, and make the maximum damage bounded. A three-retry cap turns a potential 319-retry storm into a 30-second hiccup.

The question to ask about any agent system isn't "how smart is the agent?" It's "what's the worst thing this agent can do?" If you can't answer that question for every agent in your system, your blast radius is unbounded. And as AWS learned, unbounded blast radius eventually finds its target.

Next time: Stripe Webhooks in Rails — the gotchas nobody warns you about, from signature verification to idempotency races.