What Is AI Agent Blast Radius?

AI agent blast radius is the range and scale of harm a particular deployment could cause if it acts incorrectly, is manipulated, or is used through an overbroad identity. It includes the data exposed, resources changed, recipients reached, and duration before the organization can stop further action.

I use it as a scenario-based review, not a numerical security score. A read-only assistant with confidential documents can cause a serious disclosure. An agent that can deploy code adds integrity and availability risks. The available data and authority determine which scenarios need attention.

Why Prompt Injection Is Too Narrow

Prompt injection is real, but prompt injection alone does not describe business impact.

A prompt-injected chatbot may produce an incorrect answer.

A prompt-injected agent may:

Send an email.
Modify a customer record.
Exfiltrate sensitive data.
Trigger an API call.
Poison memory.
Create a ticket.
Deploy code.
Delete a file.
Leak secrets.
Take repeated autonomous action.

OWASP's 2025 LLM Top 10 includes prompt injection and excessive agency. For a blast-radius review, connect the failure to a reachable resource and an observable effect.

For agentic systems, OWASP specifically calls out tool abuse, privilege escalation, data exfiltration, memory poisoning, goal hijacking, excessive autonomy, cascading failures, and sensitive data exposure.

Inspect the proposed action and downstream effect separately. A manipulated model can reach a working deny rule; a normal model can still call an overbroad API.

A Working Definition

AI agent blast radius is determined by seven dimensions:

Dimension	Question
Data access	What can the agent read?
Action authority	What can the agent write, delete, send, execute, or approve?
Credential scope	What identities, tokens, service accounts, or OAuth scopes does it inherit?
Autonomy	Can it act repeatedly or without human approval?
Tool chaining	Can low-risk tools combine into high-risk outcomes?
Persistence	Can it store poisoned memory or alter future context?
Observability	Can the organization reconstruct what happened?

For each scenario, write a concrete bound: one assigned ticket, one customer tenant, one approved recipient, two writes per run, and a tested disable path. Then test the assumptions behind that bound. If the credential can read every tenant, a documented one-tenant workflow does not establish containment.

Low, Medium, High, And Critical Blast Radius

Not every AI workflow is equally risky.

Blast Radius	Example	Risk Profile
Low	Internal FAQ chatbot with public docs only	Bad answers, limited exposure.
Medium	Support assistant with read-only ticket and customer context	Sensitive data leakage, bad recommendations.
High	Agent that can update CRM records, create tickets, draft emails, and query internal systems	Unauthorized changes, data exposure, workflow abuse.
Critical	Agent with write access to production systems, billing, cloud APIs, source code, deployment, or shell execution	Business disruption, security compromise, financial or legal impact.

The same model can carry different risks in different workflows. Authority, data sensitivity and the consequences of a wrong answer change the assessment.

Blast Radius Starts With Data Access

The first blast-radius question is what the agent can see.

Data Class	Example	Blast-Radius Concern
Public data	Docs, marketing pages, public support articles	Low confidentiality impact.
Internal data	Policies, project docs, internal tickets	Internal exposure and business leakage.
Customer data	CRM, support cases, contracts, PII	Legal, trust, and contractual impact.
Secrets	API keys, tokens, credentials, private keys	Direct compromise path.
Regulated or controlled data	Health, financial, legal, export-controlled, or sensitive client data	Compliance and liability impact.
Source code	Repositories, CI/CD metadata, deployment configs	Supply-chain and infrastructure risk.

Data access should be enforced before content enters the model context. A prompt that says "do not reveal unauthorized data" is not an access-control system.

Action Authority Is The Multiplier

Data access creates exposure. Action authority creates impact.

Classify every action the agent can take:

Action Type	Examples	Risk
Read	Search, list, summarize, retrieve	Data leakage.
Draft	Draft email, draft ticket response, draft change	Human-review dependent.
Write	Update record, create issue, modify field	Integrity impact.
Delete	Delete document, remove user, close case	Irreversible damage.
Send	Email customer, post Slack message, submit form	External business impact.
Execute	Run code, shell command, workflow, deployment	System compromise.
Approve	Refund, payment, access change, legal/compliance step	Financial/legal impact.

Separate actions into classes and apply controls appropriate to each resource and effect. A bounded automated write can be reasonable when the business policy and recovery behavior are explicit.

Credential Scope Determines Real Power

An agent does not have power because it is intelligent. It has power because credentials allow it to act.

Review:

Credential Type	Risk Question
User OAuth token	Is action scoped to the initiating user?
Shared service token	Does the agent inherit organization-wide authority?
API key	Is it long-lived and overbroad?
Cloud role	Can the agent affect infrastructure?
Local secret	Can a local MCP server access developer credentials?
Database credential	Does it bypass application-layer authorization?

MCP security guidance discusses authorization and OAuth-related risks, including confused deputy problems and the need for per-client consent, redirect URI validation, and state validation.

Narrow credentials reduce reachable resources, but an authorized operation can still be harmful. A valid token for one customer mailbox can expose that mailbox; scope reduction does not make the remaining action harmless.

Tool Chaining Creates Hidden Risk

Individual tools may look safe in isolation.

The combination may not be safe.

Tool	Appears Safe?	Combined Risk
`search_docs`	Yes	Can retrieve sensitive source material.
`summarize_text`	Yes	Can transform sensitive content for exfiltration.
`send_email`	Maybe	Can transmit the summary externally.
`update_ticket`	Maybe	Can persist malicious instructions into workflow.
`create_calendar_event`	Low	Can socially engineer internal users.

The review should ask:

Can output from one tool become input to another?
Can the agent chain read -> summarize -> send?
Can the agent convert internal data into external communication?
Can it persist attacker-controlled content into future workflows?
Can it move from low-risk tools into high-risk actions?

Blast radius is often hidden in the chain, not the individual tool.

Persistence Changes The Threat Model

Memory increases usefulness and risk.

Memory can include:

User preferences.
Prior tasks.
Business context.
Learned facts.
Tool results.
Workflow state.
Retrieved content.
Long-term notes.
Summaries of past interactions.

If memory is not validated, scoped, and isolated, it can become a persistence mechanism for malicious context.

Questions to ask:

Memory Control	Review Question
Scope	Is memory isolated by user, tenant, role, and workflow?
Source	Does memory preserve where information came from?
Trust	Are untrusted memories labeled differently?
Expiration	Does memory expire or require revalidation?
Modification	Can users or external content alter durable memory?
Review	Can memory be inspected, deleted, or corrected?

An agent with unsafe memory can remain compromised after the original prompt injection is gone.

Observability supports containment and reconstruction

Logging does not prevent every failure, but it changes response and remediation.

A system with strong observability can answer:

Who initiated the workflow?
What did the user ask?
What documents were retrieved?
What tool did the agent call?
What parameters were generated?
What authorization decision occurred?
Was human approval required?
What did the downstream system do?
What was shown or sent externally?
What memory was read or written?

Without those traces, the team may be unable to determine the affected scope. Logging alone does not shrink the agent's permissions, and lost events limit what surviving records can establish.

Sample Blast-Radius Matrix

Use these qualitative labels to start a discussion, not as a scoring formula or an automatic severity assignment. Context and combinations matter: one privileged record may be more consequential than thousands of public records.

Dimension	Low	Medium	High	Critical
Data access	Public docs	Internal docs	Customer data	Secrets / regulated data
Tool authority	Read-only	Draft/create	Write/send	Delete/execute/deploy
Credentials	No credentials	User-scoped	Broad app token	Admin/service token
Autonomy	Single response	User-approved action	Multi-step workflow	Autonomous loop
Tool chaining	None	Limited	Read -> write	Read -> exfiltrate/execute
Memory	None	Session-only	Long-term user memory	Cross-user or shared memory
Logging	Full trace	Partial trace	Minimal logs	No reconstruction possible

How To Reduce AI Agent Blast Radius

Blast-radius reduction is mostly an engineering problem.

Control	Effect
Least-privilege tools	Reduces what the agent can do.
User-scoped authorization	Prevents shared-token overreach.
Per-tool allowlists	Prevents unintended action paths.
Human approval gates	Stops high-impact autonomous actions.
Draft-first workflows	Prevents direct external communication.
RAG authorization enforcement	Prevents unauthorized context exposure.
Output validation	Stops malformed or hostile tool parameters.
Sandboxed execution	Contains code and shell risks.
Egress controls	Limits data exfiltration.
Memory isolation	Prevents persistent cross-user poisoning.
Full trace logging	Supports detection, response, and accountability.
Kill switch	Allows rapid containment.

Choose controls that preserve the useful task while bounding the plausible harm. Some high-impact capabilities may need to stay outside the agent altogether.

What A Blast-Radius Review Should Leave Behind

The review should make the agent's authority visible. A team should be able to point to the tools, credentials, approval gates, and logs instead of relying on a vague promise that the model will behave.

Deliverable	Description
Tool Inventory Matrix	Lists every tool and what it can read, write, delete, send, or execute.
Credential Scope Review	Identifies overbroad tokens, shared service accounts, and missing attribution.
Action Classification Table	Groups actions by impact and required control.
Trust-Boundary Diagram	Shows where untrusted input crosses into model context or system action.
Abuse-Case Matrix	Documents realistic prompt, tool, retrieval, and memory failure modes.
Blast-Radius Reduction Plan	Prioritizes scope reduction, approval gates, sandboxing, and logging.
Go/No-Go Memo	States whether the workflow is production-ready, pilot-only, or blocked.

Verify a boundary before expanding it

Take one workflow, such as reading a ticket and drafting a reply, and identify the worst plausible effect within its actual permissions. Test whether the agent can select another tenant, change the recipient, reuse an approval, or keep acting after revocation. Add the downstream result to the matrix rather than recording only the model's request.

Expand access only when the team can explain the new failure scenarios and who owns their containment. The permission guide provides a concrete implementation path.