Blast Radius Engineering: Tool Permission Design for AI Agents

Teams often talk about agent safety as if the core problem were prompt quality. It usually is not. The real production question is simpler: if this agent does the wrong thing, how much damage can it do before the system notices and stops it?

That is a blast-radius question.

Once an AI agent can search internal systems, draft outbound actions, update tickets, call workflows, or trigger write paths, permission design becomes part of the architecture. Without explicit blast-radius modeling, teams rely on prompts, good intentions, and weak conventions to control real operational risk.

Blast radius engineering makes tool permissions narrow, reviewable, and proportionate to the consequences of failure.

Diagram 1: Blast radius engineering turns prompt-era permission guesswork into an execution boundary with identity, policy, approval, and tool-level controls.

Tool Permission Design Starts With Consequence

The better question is: what is the maximum consequence this agent should be allowed to create without additional review?

A support agent may “need” access to billing records, CRM notes, ticket history, and refund tools. But the correct design is not to hand it all of those capabilities under one generic scope. The correct design is to separate data lookup, draft generation, human-approved writes, and irreversible or customer-visible actions.

Model The Permission Contract Outside The Prompt

The permission contract should answer four things explicitly: who is acting, what tool is being requested, what resource scope is allowed, and what control path applies before execution.

class BlastRadius(str, Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"

class ApprovalMode(str, Enum):
    AUTO = "auto"
    HUMAN_REVIEW = "human_review"
    DUAL_CONTROL = "dual_control"

class ToolPermission(BaseModel):
    tool_name: str
    blast_radius: BlastRadius
    tenant_scoped: bool = True
    allowed_actions: list[str] = Field(default_factory=list)
    max_records: int | None = None
    requires_structured_validation: bool = True
    approval_mode: ApprovalMode
    reversible_within_seconds: int | None = None

That model is the basis for every later decision: which tools can run automatically, which actions require a person in the loop, and which actions should never be agent-owned at all.

Segment Read, Suggest, Write, And Irreversible Actions

Letting one permission tier span multiple action types is how blast radius expands quietly. A cleaner pattern separates read (fetch and inspect data), suggest (prepare a recommendation or structured draft), write (modify an internal system after explicit gating), and irreversible (actions that require hard review or deterministic ownership).

The common trajectory for teams that skip this segmentation: the prototype gave the agent “full access for now,” the scope never got narrowed before production, and six months later a permission audit reveals that read, suggest, write, and irreversible actions are all running under the same token with no approval differentiation between them.

Delegation Must Narrow Permissions, Never Widen Them

This is the multi-agent rule teams violate most often. If a parent agent has bounded access and then delegates to a specialist, the specialist should inherit the same tenant boundary, a narrower task scope, the same or stricter approval mode, and no new write capability unless explicitly granted by policy.

def derive_child_scope(parent_scope: ToolPermission, child_tool: str) -> ToolPermission:
    allowed = {
        "search_crm": ["read"],
        "draft_refund_summary": ["suggest"],
        "submit_refund_request": ["write"],
    }
    child_actions = allowed.get(child_tool, [])
    child_is_write = "write" in child_actions

    return ToolPermission(
        tool_name=child_tool,
        blast_radius=parent_scope.blast_radius,
        tenant_scoped=parent_scope.tenant_scoped,
        allowed_actions=child_actions,
        max_records=parent_scope.max_records,
        requires_structured_validation=True,
        approval_mode=(
            parent_scope.approval_mode
            if not child_is_write
            else ApprovalMode.HUMAN_REVIEW
        ),
        reversible_within_seconds=parent_scope.reversible_within_seconds,
    )

The important detail is the policy shape: child scopes should be derived, not invented ad hoc by the model.

Gate Execution With Policy, Validation, And Approval

A real gate should combine identity context, tenant scope, tool permission contract, structured argument validation, and approval policy.

Static allowlists help for low-risk read paths. Once the system has conditional logic, workflow context, or business-state sensitivity, you usually need a policy layer that reasons over context as well.

def evaluate_tool_execution(
    identity, permission: ToolPermission, payload: dict
) -> tuple[bool, str]:
    if permission.tenant_scoped and payload.get("tenant_id") != identity.tenant_id:
        return False, "Tenant scope mismatch."
    if "write" in permission.allowed_actions and permission.approval_mode == ApprovalMode.AUTO:
        return False, "Write action cannot bypass approval mode."
    if permission.blast_radius in {BlastRadius.HIGH, BlastRadius.CRITICAL}:
        if not payload.get("validated"):
            return False, "Structured validation missing."
    if permission.blast_radius == BlastRadius.CRITICAL and not payload.get("reviewer_id"):
        return False, "Critical action requires reviewer signoff."
    return True, "Execution permitted."

The underlying principle is stable: no agent should reach a high-impact tool path through prompt compliance alone. This is one of the structural checks in our PRISM methodology under G2 (Architecture Audit) and G3 (Adversarial Validation).

The opinionated position worth stating plainly: a prompt that says “only perform reversible actions” is not a permission boundary. It is a suggestion to the model. A ToolPermission contract evaluated in deterministic code before execution is a permission boundary. Teams that treat these as equivalent are not operating a controlled system — they are operating an uncontrolled system with good documentation.

Use Blast Radius To Decide What Stays Deterministic

If a step has low ambiguity, a stable ruleset, high failure cost, and little reasoning upside, then it often belongs in deterministic code with the agent upstream of it, not in the agent itself. Examples include applying a known refund policy, formatting a structured outbound payload, enforcing field-level write constraints, and checking whether an action requires two-person approval.

This pattern appears when teams try to use the agent to apply business rules that are already fully specified: the model adds latency, cost, and non-determinism to a decision that a function could make in microseconds with zero error rate. Blast radius analysis makes this visible — if a step’s failure mode is “wrong rule applied” rather than “wrong reasoning path taken,” it belongs outside the model layer.

Add Release Discipline To Permission Changes

A good rollout rule for tool-permission changes:

• Every new tool or permission tier gets a named blast-radius class.
• High and critical classes require one explicit reviewer path before first production use.
• Permission changes run through the evaluation suite for routing, tool selection, and validation failures.
• Critical actions must show zero regressions on the protected-case set before rollout.
• Policy and tool-contract changes are written as ADRs, not left in Slack memory.

The best companion asset for this topic is the Architecture Decision Records Kit, because permission design is exactly the kind of system choice that becomes expensive when it stays undocumented.

What A Good Blast-Radius Review Usually Finds

When we review agent systems with live tool access, the same findings recur: write permissions granted under prototype-era assumptions, managers with broader tool access than specialists, no distinction between reversible and irreversible actions, delegated agents inheriting too much scope, reviewer steps added operationally but not encoded architecturally, and prompt-level policy trying to compensate for absent execution-layer controls.

That does not mean the whole system is wrong. It usually means the team needs to redesign the permission boundary before more capability is added on top.

FAQ

Engineer The Boundary Before The System Hardens

Tool permission design is one of the fastest ways a promising agent system turns into a production liability. Blast radius engineering forces the system to answer the uncomfortable questions early: what can this agent actually do, what happens when it is wrong, who has to approve which class of action, and which steps should stop being agentic altogether.

The Decision Rule

If your agent workflow already uses tools or is about to, use the Architecture Decision Records Kit to document blast radius, approval boundaries, and rollback assumptions before the tool surface hardens.