Every Agent Has a Blast Radius

An AI agent's risk is often described by its intended job. "It's a customer-service agent." "It reviews transactions." "It helps the collections team." Those descriptions are useful, but they leave out the part that matters most when something goes wrong.

What can the agent actually do?

That is where blast radius becomes useful. The term comes from engineering, where it describes how much of a system can be affected by one failure. The same idea applies to AI agents. Before putting an agent into production, a company should understand the furthest a bad, manipulated, or misdirected action could reach before someone or something stops it.

The agent's job is not its boundary

A collections agent that reads account balances has a different risk profile from one that can change payment status, issue refunds, and message customers without review. Both might be described internally as "collections automation." Their permissions tell a more useful story.

The same applies in other workflows. A fraud agent that recommends freezing an account is one thing. A fraud agent that can freeze the account itself is another. A support agent that drafts a response is different from one that can send it, update a customer record, and trigger a refund.

The intended use of an agent does not define its maximum impact. Its access and authority do.

That is why "the agent is only meant to answer questions" is not a control. Intent is useful context. Permissions are the boundary.

Six questions to ask before deployment

A practical blast-radius review can start with six questions. Some answers may be visible in tool definitions and permission scopes. Others require looking at the workflow and the way the agent operates.

1. What can it access?

List the systems, APIs, databases, and data sources the agent can reach. Read-only access to a single system is very different from write access across customer, payment, and communication systems.

The question is not what the team expects the agent to use. It is what the technical setup allows it to use.

2. What actions can it take?

Reading data is not the same as changing it. Updating a support ticket is not the same as modifying a payment record. Sending a draft for review is not the same as sending a customer notice.

Separate informational actions from operational changes, and operational changes from actions with financial, legal, customer, or reputational consequences.

3. How many records or people are in scope?

An agent working on one customer record at a time has a narrower radius than one that can run across a large queue or customer segment.

A single action may look harmless in isolation. The same action repeated across thousands of accounts can become a very different problem.

4. Can the action be reversed?

Some changes are easy to undo. Others are difficult, expensive, or impossible to reverse.

A record may be restored from a backup. A refund may be recovered. A message sent to a customer cannot be unsent. A payment sent to the wrong account may not be recoverable at all.

Reversibility is not binary. It exists on a spectrum, and less reversible actions generally deserve a stronger control before execution.

5. How quickly can it act?

An employee may make a few decisions in an hour. An agent can repeat an action continuously or process a large queue in a short period.

Speed matters because it reduces the time available to notice a bad pattern. The problem is not only that an agent can make a mistake. It can make the same mistake many times before anyone understands what is happening.

6. How long would it operate before anyone noticed?

This is separate from execution speed. An agent may act quickly but be reviewed continuously. Another may act at a moderate pace while running for an entire shift without meaningful review.

The detection window matters. An agent with broad access and no timely intervention path has a larger practical blast radius than the same agent under close supervision.

A simple scoring exercise

You do not need a sophisticated risk platform to begin. A basic low, medium, and high assessment across these dimensions can expose gaps that are easy to miss in a product description.

• Access scope. Low: read-only, single system. Medium: read/write, single system. High: write access across several systems.
• Action type. Low: informational. Medium: reversible operational change. High: financial, irreversible, or customer-facing.
• Population affected. Low: single record. Medium: defined segment. High: large batch or broad population.
• Reversibility. Low: fully reversible. Medium: partially reversible. High: difficult or impossible to reverse.
• Execution speed. Low: manual trigger. Medium: scheduled or batched. High: continuous or high-frequency.
• Detection and intervention. Low: reviewed in real time. Medium: reviewed within hours. High: unreviewed for a full shift or longer.

The score is not a compliance certification. It is a way to force a more honest conversation about what the agent can reach and what happens when its assumptions are wrong.

An agent does not need to score high in every category to deserve additional controls. A single high-consequence capability may be enough. An agent that can release payments, change account status, or send external communications may require a different boundary even if its other permissions are narrow.

An illustrative example

Consider a hypothetical fraud-review agent at a mid-sized lender.

Its stated purpose is reasonable: review flagged transactions and recommend what should happen next. But suppose it can also freeze customer accounts, operate across the full review queue, and run continuously against live data.

The agent has access to sensitive account and transaction information. Freezing an account is consequential and only partly reversible. The agent can affect a broad population rather than one customer at a time. If the queue is processed continuously and the pattern is reviewed only once a day, dozens of accounts could be frozen before anyone notices that the agent is behaving incorrectly.

The problem is not necessarily the stated purpose. The problem is the gap between the description of the agent and the authority granted to it.

That gap is where a blast-radius review earns its keep.

Reduce the radius before increasing the autonomy

The best time to assess an agent's blast radius is before it touches production. The assessment should then be revisited whenever the workflow changes.

A new tool can expand the radius. A read permission can become a write permission. A new data source can expose sensitive information. Removing a human approval step can change the consequences of failure. Increasing the volume or operating hours can make an existing permission much more dangerous.

For each consequential capability, define the control that should apply. If the agent can read customer PII, restrict the data scope and record access. If it can modify a payment record, limit which records and operations are permitted, and require approval where the consequences warrant it. If it can issue a refund, apply transaction limits and put a decision boundary before execution. If it can send a collections message, enforce communication rules and review sensitive cases. If it can call an external API, restrict the endpoint, method, parameters, and frequency.

The goal is not to remove autonomy. It is to make autonomy proportional to the consequences of being wrong.

Monitoring is not containment

Most organisations have some form of monitoring. That is useful, but monitoring and containment solve different problems.

A system that reports an unusual payment after it happens may help with investigation. It does not prevent the payment from happening.

Gateplex sits between an agent and the system it is trying to act on. It evaluates the proposed action against configurable rules before execution and returns one of four outcomes:

• ALLOW means the action proceeds.
• FLAG means a rule matched, the action proceeds, and the event is recorded for review.
• BLOCK means the action is stopped.
• PENDING_APPROVAL means the action does not proceed until an authorised human approves or rejects it.

These outcomes should not be collapsed into one vague description such as "human-in-the-loop." FLAG provides visibility while allowing the action to continue. PENDING_APPROVAL creates a decision boundary before execution. BLOCK prevents the action altogether.

That difference matters. Reviewing a completed action is not the same as deciding whether the action may happen.

Blast radius is an architecture question

The usual discussion about AI agents asks whether the model can be trusted. That question matters, but it is incomplete.

A model can be accurate most of the time and still be attached to too much authority. It can be manipulated by an unexpected input. It can misunderstand a request. It can follow a valid instruction in the wrong context. It can encounter a failure mode that was not represented in testing.

The surrounding architecture determines what happens next.

A low-risk agent may be allowed to act independently. Another may be allowed to act but flagged for later review. A consequential action may need PENDING_APPROVAL. Some actions should be blocked regardless of the model's confidence.

Autonomy is not a switch. It is a set of permissions and decisions applied to specific actions.

Every agent has a blast radius. The practical questions are straightforward:

• What can it reach?
• What can it change?
• How many times can it do it?
• How quickly would anyone know?
• What stops it before the action becomes a consequence?

Those questions are easier to answer before an incident than after one.

Gateplex offers a fixed-fee, 30-day Shadow Compliance Audit in observation-only mode, with no changes to agent logic. It helps organisations understand what their agents can reach and how those actions behave in live workflows.

This article describes a governance approach, not legal or compliance advice. Specific control requirements depend on the organisation, workflow, systems, and applicable obligations.