What Is AI Agent Blast Radius?
AI agent blast radius is the maximum plausible damage an agent can cause if manipulated, misconfigured, over-permissioned, or exposed to hostile context.
AI agent blast radius is the range and scale of harm a particular deployment could cause if it acts incorrectly, is manipulated or uses an overbroad identity. It includes data disclosed, resources changed, recipients reached and the time during which further action remains possible.
Assess it through scenarios. A read-only assistant with confidential documents can cause a serious disclosure. An agent that deploys code adds integrity and availability risks. Neither the model name nor a generic autonomy score tells you how far this deployment can reach.
Start with a support workflow
Suppose an assistant searches one customer's tickets and drafts replies. A hostile ticket asks it to retrieve another customer's attachment and email the contents elsewhere.
There are several possible outcomes. Retrieval may reject the second customer's document. The model may request it but never receive it. The system may expose the attachment in context, or go further and send it. Each result crosses a different boundary and needs a different correction.
OWASP's LLM risk guidance includes prompt injection and excessive agency. A blast-radius review connects those categories to the resources this assistant can actually reach. It also covers mistakes and misconfiguration; the model need not be manipulated to call an overbroad API.
Put concrete bounds on the scenario
| Dimension | Question for the support assistant | A bound to test |
|---|---|---|
| Data | Which tickets and attachments can enter context? | Only records assigned to the initiating user in the selected tenant. |
| Actions | Can it draft, send or change account state? | Draft creation only; external sending is unavailable in this pilot. |
| Credentials | What else can the token or process access? | No other tenants, mailbox administration or deployment access. |
| Repetition | How much work can run before it stops? | Defined call, time and concurrency limits enforced by the runtime. |
| Chaining | Where can retrieved content go next? | No unapproved export or transfer to another destination. |
| Persistence | Can a bad instruction affect another task? | Task-scoped state with a defined expiry and correction path. |
| Recovery | How is further action stopped and the result established? | A tested disable procedure and correlated downstream records. |
These are sample restrictions, not claims about a deployed assistant. Set values from the business use and test the implementation. A one-tenant workflow description offers little containment if the runtime credential can read every tenant.
Read access can be the consequential permission
Confidentiality impact depends on the content and its destination. One record containing a live credential can expose more resources than thousands of public pages. A mailbox, legal matter or customer archive can be sensitive even when the agent cannot write to it.
Enforce permission before protected content reaches a model, external reranker or user. Include summaries, citations and cached answers; hiding the raw document does not prevent a derived response from disclosing it.
Keep credentials out of ordinary context. Inspect the process environment, local MCP configuration, file access and network routes as well as the tool registry. A credential that bypasses application policy changes the scenario even if no advertised tool uses it intentionally.
Rate actions by their target and effect
Read, draft, write, delete, send, execute and approve are useful inventory labels. They are not automatic severity ratings. A draft visible only to its author differs from a draft saved into a shared customer workspace. A bounded update to a disposable test record differs from a change to billing or access control.
For each operation, identify the target, affected audience, reversibility and business authority. A bounded automated write may be reasonable when policy and recovery are explicit. More consequential operations may need a person to approve the exact request or may remain outside the agent entirely.
Validate both structure and permission. A well-formed message can have an unauthorized recipient, and a valid token can still be too broad for the intended task.
Review combinations and repeated work
Search, summarization and sending can each be permitted while the combined transfer is forbidden. Follow the data through the complete chain and check the destination at the point it leaves the protected context.
Then account for repetition. A mistaken change performed once may be recoverable; the same change across an entire tenant may not be. Limits on call count, concurrency, time and cost only reduce the reachable impact if every execution path enforces them.
Test uncertain results too. A timeout after dispatch does not establish that an operation failed. Retrying without reconciliation can multiply the effect. Where supported, bind idempotency to the intended operation and confirm the downstream contract.
Include what survives the conversation
An agent may store a false instruction or incorrect summary in memory, a ticket, a document or an index. Ending the session does not remove those copies. Identify who may write durable state, how it is scoped and how later tasks retrieve it.
Retain source and derivation references so corrections can reach affected records. Test revocation with a warm cache and a running worker. A source removed from search may still appear in an answer cache or citation preview.
The memory review guide follows these lifecycle questions through a pilot. Persistent state should have an owner and an end condition, not merely a storage location.
Measure the stop path
Disable the affected tool under the normal operator role. Determine whether new work is rejected, queued jobs stop and in-flight operations can finish. Record the time and remaining authority. An interface toggle that leaves a worker running does not establish containment.
Logs help identify affected resources and reconcile uncertain work. They do not shrink permissions by themselves. Preserve the initiating identity, source references, action, policy result and downstream observation while controlling sensitive content and log access. Missing events limit the conclusions the remaining trace can support.
Use the findings to choose the next permission
The review should produce a scenario register tied to the actual tools, credentials and controls. Each entry needs the reachable effect, tested bound, unresolved assumption and owner. Explain why a proposed restriction reduces the relevant harm and how the legitimate task continues to work.
For the support pilot, that may mean allowing ticket reads and drafts while withholding send authority. Before adding sending, test recipient changes, attachment access, approval reuse and revocation against the connector that will run.
The secure tool-access guide provides an implementation example. Use it to test a concrete permission, then record the result before expanding access.