What is blast radius analysis?

Blast radius analysis predicts the scope of impact if a proposed change or agent action fails: which services, users, or transactions would be affected, and to what degree. Knowing that bound lets a team ship a change, or let an agent act, with the worst case known before it runs. In AI agent governance, blast radius is a runtime enforcement primitive. An action is only allowed if its predicted impact falls within an approved bound.

How NOFire AI does blast radius analysis. NOFire AI, a production ops platform for engineers and AI agents, computes blast radius on a live production map. The map is built from observed traffic, deploy history and configuration rather than from a catalog file someone maintains, and it versions every state over time. That versioning makes the context deterministic. You can ask what the agent knew when it proposed an action, where that came from, and what changed after. Before a deploy ships, NOFire AI places the change on that map and returns the services, owners and critical paths the change can reach. The team then ships knowing which services and owners a failure could touch. During an incident it runs the same traversal from the symptom back to the change that caused it, then forward again to show what else that change is affecting. When an AI agent proposes an action, NOFire AI checks its predicted blast radius against runtime policy. If the impact exceeds the bound, the action is refused or held for a person.

Blast radius in deployment

Before a deploy ships to production, blast radius analysis answers a set of scoping questions: if this fails, what percentage of traffic is affected? Which downstream services depend on this one? Can the failure be contained to a canary slice?

These questions are not theoretical. A change that touches a shared authentication service has a different blast radius than a change to an isolated batch job. Canary deployments constrain blast radius by design. Only a defined slice of traffic reaches the new version, so a failure can spread no further than that slice before it is detected and rolled back.

Blast radius analysis makes this constraint explicit and measurable. Rather than relying on intuition about which services are critical, it traces the dependency graph to produce a bounded scope before the change ships.

Blast radius in AI agent governance

When an AI agent proposes to restart a service, roll back a deploy, or change a configuration, the blast radius of that action should be computed before it executes. This is not optional in high-availability environments. There, the availability target leaves a small error budget (the downtime the SLO allows). One action that reaches past its scope can spend that budget for every service it touches. An agent acting without blast radius awareness can trigger a cascade that affects services and users far outside the intended scope of its task.

The control for that cascade is a check before execution. Each proposed action carries a predicted blast radius, and a runtime policy defines the maximum allowed bound. If the predicted impact exceeds the policy bound, the action is refused or escalated to a human operator. This makes blast radius a hard gate that the agent cannot override.

This is one of the core patterns covered in the Runtime Policy Patterns. NOFire AI applies blast radius bounds as a runtime enforcement layer, so agents operate within approved scope even when acting without a human on live infrastructure.

The same patterns define three controls around that gate:

• Human approvals. An action held for a person runs only after a person approves it. For high-blast actions, a quorum gate requires N-of-M approvals, human or peer agent, before execution. The approval and the approver become part of the signed audit record. How to implement runtime policy enforcement for AI agents covers setting up the approval flow.
• Kill switch. A single control halts all unattended execution at once, with a defined recovery procedure. It does not need the agent's cooperation.
• Circuit breakers. A burst of actions can pass the per-action check one action at a time. Rate limits per agent, per service and per action type act as a circuit breaker and throttle the burst before its combined impact compounds.

Prompt injection (text in the agent's input that tells it to act) meets the same gate. An injected instruction still has to produce an action, and that action gets the same blast radius check as any other. A sandbox limits what the action can reach, and the policy decides whether it runs at all.

How it works in practice

A live dependency graph makes blast radius calculable. Given a proposed action on service X, a graph traversal identifies all services that receive traffic from X, the traffic share carried by each, and whether X sits on a critical path.

The result is a bounded scope: "if this action fails, up to N% of checkout traffic and M% of notification delivery are affected." This is specific enough to enforce against a policy threshold and specific enough to inform a human reviewing an escalation.

Without the dependency graph, the analysis degrades to rough estimation. Traffic percentages alone tell you how much load a service carries but not which downstream consumers depend on it. A service that handles 3% of direct traffic may be a synchronous dependency for a service that handles 60%. Estimation without graph traversal will consistently undercount indirect impact.

Several inputs feed a reliable blast radius computation:

• Service dependency graph: which services call which, and in what mode (synchronous, asynchronous, fan-out).
• Traffic share: the fraction of total request volume that passes through the target service.
• Criticality classification: whether the service is on a path that, if broken, causes a hard failure versus a degraded experience.
• Isolation boundaries: whether circuit breakers, queues, or caching layers can absorb a failure before it propagates.

Together these inputs produce a scope estimate that is specific, revisable as the graph changes, and enforceable as a policy condition.

Blast radius vs risk score

Risk scores and blast radius address related but distinct questions. A risk score is probabilistic: it estimates the likelihood that a change will cause a problem. Blast radius is scope-bounded: if this fails, up to N% of checkout traffic is affected, regardless of how likely failure is.

Both are useful in a governance context, because governance makes two separate decisions. It decides which actions a person reviews, and it decides which actions can run at all. Risk scores inform prioritization and review thresholds. Blast radius informs enforcement. An action with a low risk score but a large blast radius still warrants a policy check, because even an unlikely failure at large scope is consequential.

The practical difference is actionability. A risk score answers "should I be worried?" Blast radius answers "how bad could it get?" For runtime enforcement, the second question is more directly enforceable: you can write a policy that refuses actions with a blast radius above a defined threshold. Writing a policy against a probabilistic score requires an additional judgment layer.

This distinction matters when designing agent governance policies. Blast radius bounds give agents a clear, computable constraint. Risk scores are better suited to surfacing actions for human review when the situation is ambiguous.

See the Runtime Policy Patterns to go deeper on how blast radius bounds fit into a complete runtime enforcement model.

This page defines the term. For how the figure is computed, how the approaches compare and how a prediction is checked against what happened, see blast radius, in practice. To draw and estimate it for a deploy before it ships, see how to visualize deployment blast radius.