What sets an AI agent’s blast radius?
Three factors, all chosen at deployment. How many systems the agent can reach, directly or through tools. How long its credentials stay valid. And how fast its access can be revoked when something looks wrong. An agent on a long-lived, shared service account inherits the blast radius of that account, not of its task: one over-permissioned agent can expose every downstream database and internal service it was never meant to need. Agent authorization is the discipline of making those choices deliberately.
Why do chained tool calls make it worse?
Because agents compose actions. A single tool call is easy to police; a sequence of individually harmless calls is not: read the customer table, summarize it, post the summary to an external channel. Each step passes review on its own while the chain exfiltrates data, which is why per-action allowlists alone underestimate the risk, and why AI agent security reviews what sequences are possible, not just what calls are allowed.
How do you shrink the blast radius before deployment?
Four controls, in order of value. Least privilege: the agent gets its own identity with the minimum scopes, never a human’s credentials. Short-lived credentials, so stolen access expires on its own. Isolation: risky work runs in sandboxed code execution where a bad action cannot reach production. And a rehearsed agent kill switch that cuts access in seconds. Size the blast radius before granting the permissions, not after the incident report.
How do you reason about blast radius as a buyer?
Ask the vendor or your own team one question per integration: if this agent went fully wrong for an hour, what is the worst it could do here? If the answer is “nothing irreversible”, the permission is probably right; if the answer takes a meeting, the permission is too wide. The exercise costs an afternoon and usually strips a meaningful share of the scopes an agent was casually granted, the fastest risk reduction available in agentic AI deployments.