Authorization and Blast Radius Control for Agents
A practical model for controlling scope, autonomy, sequence, and consequence when agents act across enterprise systems.
One thing I keep thinking about in agentic AI is authorization and blast radius control.
Many employee-facing enterprise workflows were designed around a person using one interface, taking one action at a time. We added formal controls at the service and API layers, but we also came to rely on several informal constraints: a person had to navigate the interface, gather context, move between systems, and spend time on each step.
Agents change those assumptions. They can use the same enforced permissions while moving across systems, combining information, and chaining actions much faster than a person. The risk is not that an agent magically bypasses a real backend control. The risk is that credentials and actions that were reasonable inside a slow human workflow can create a different consequence when they are automated and combined.
Human workflows carried hidden safety assumptions
| Dimension | Human-operated workflow | Agent-operated workflow |
|---|---|---|
| Pace | A person works through actions sequentially | The system can act at machine speed unless deliberately limited |
| Path | The user usually follows a visible interface flow | The agent can call tools and APIs across systems |
| Context | The person brings situational knowledge, even when it is incomplete | The agent sees only the context provided or retrieved |
| Sequence | Friction separates one action from the next | Individually allowed actions can be chained into a new outcome |
| Implicit containment | Attention and time naturally restrict volume | Rate limits, budgets, and policy have to create the restriction explicitly |
The underlying systems and permission models will take time to evolve, so this cannot depend on a future platform redesign. The controls have to work with the systems companies have now.
Authorization has to travel with the action
Traditional role-based access control remains necessary. It can establish who has a role and which resources that role may access. It does not, by itself, answer several questions that become important for an agent:
- Is the agent acting as itself, through a service account, or on behalf of a person?
- Which records and systems belong inside this task?
- May it read, recommend, or execute?
- Is it allowed to repeat the action or combine it with another action?
- What approval is required for this context and consequence?
- Can the action be prevented, staged, reversed, or compensated if it is wrong?
Visual summary
Authorization has to survive the full action path
Scope
Identity + data boundary
Who or what is acting, on whose behalf, in which system, and over which records?
Autonomy
Read / recommend / execute
Each action mode needs a distinct permission and an explicit execution budget.
Sequence
Single action or chain
Individually allowed steps can create a new risk when combined across systems.
Containment
Approval + recovery
Use contextual gates, rate limits, staged commit, or compensating action before consequences expand.
Why it matters: authorization for agents must govern the path, not only the credential at the beginning.
This is why I think of authorization as a path rather than a single check. The identity at the beginning matters, but the action mode, data scope, sequence, volume, and consequence have to remain governed through execution.
Blast radius is a design variable
Blast radius is the maximum consequence the system can create before another control stops it. It can be measured across several dimensions:
- the number of records, accounts, or people affected;
- the number of systems crossed;
- the number of actions in a chain;
- the time window in which the agent can continue;
- the financial, operational, or human consequence;
- the ability to prevent, reverse, or compensate for the action.
Visual summary
Blast radius grows with autonomy and reach
This is a conceptual model, not a numerical risk score. Moving down or right requires stronger limits and evidence.
| System reach | Read | Recommend | Execute |
|---|---|---|---|
| One data slice | Contained visibility | Context is inspectable | Write boundary required |
| One system | Broader exposure | Cross-record effects | High operational impact |
| Chained systems | Correlation risk | Assumptions compound | Largest blast radius |
Why it matters: a permission that is reasonable for one record or one recommendation may be unsafe when repeated across systems or used to execute a chain of actions.
The matrix is intentionally qualitative. A recommendation about one record and an execution across several systems should not receive the same control simply because the same role initiated both. The further the agent moves toward execution and chained reach, the more the design needs explicit limits, evidence, approval, and recovery.
RBAC is necessary, but it cannot carry the whole design
The practical model I am using groups the problem into six control dimensions:
| Control dimension | Question the system must answer |
|---|---|
| Scope | Which systems, records, and data slices are inside this task? |
| Autonomy | Can the agent read, recommend, or execute? |
| Sequence | Which actions may be combined, repeated, or delegated? |
| Oversight | What context and consequence require approval? |
| Containment | What rate, volume, time, or value limit stops expansion? |
| Recovery | Should the action be prevented, staged, reversed, or compensated? |
Coarse, static roles cannot express all of that context. The answer is not to discard RBAC. It is to add task-scoped, sequence-aware controls around it and make the allowed blast radius an explicit design decision.
The production question I am most interested in is simple: where does your system stop an individually permitted action from becoming an unsafe sequence?