The real danger in an AI agent is not simply that it can make a wrong decision.
It is that the wrong decision may already have permission to become a production action.
As agents move from answering questions to issuing refunds, changing configuration, rotating credentials, triggering deployments, or calling other agents, authorization becomes part of the architecture itself.
The key design principle is:
Reasoning authority and execution authority should remain separate.
An agent may conclude that a refund, credential rotation, configuration update, or deployment is necessary.
That does not mean it should automatically have authority to perform that action.
The Permission Composition Problem
Agent permissions often grow gradually.
A support agent may begin with:
- transaction read access,
- customer read access,
- permission to create investigation notes.
Later, refund capability is added.
Then account-state changes.
Then merchant configuration.
Eventually the same agent can perform:
investigate
↓
decide
↓
refund
↓
change account state
↓
modify configuration
Each permission may look reasonable individually.
The risk appears when an autonomous planner can combine them.
This is why agent security is not only an API-key or IAM problem. It is also a capability-composition problem.
Prompts Are Not Authorization
A prompt such as:
Never modify permissions unless explicitly requested.
may influence behavior.
It is not an authorization boundary.
If the agent already holds credentials capable of performing the operation, the system is depending on model behavior for security.
A stronger pattern looks like this:
Agent proposes action
↓
Authorization layer evaluates
↓
Allow / Deny / Require Approval
↓
Scoped execution authority
↓
Tool executes
The model decides what it wants to do.
An independent enforcement layer decides what it is actually allowed to do.
Scope Authority to the Task
Suppose an agent is investigating transaction TX-19281.
Instead of giving broad permanent permissions such as:
transactions:read
refunds:create
the architecture should, where practical, scope authority closer to:
action: transactions.read
resource: TX-19281
workflow: dispute-7813
expires: shortly
If the workflow later requires a refund, that should trigger another authorization decision.
A successful read should not automatically create write or financial authority.
Useful authorization dimensions include:
- principal,
- initiating user,
- requested action,
- target resource,
- workflow purpose,
- duration,
- risk level.
Treat Authority-Changing Tools Differently
Not every write operation has the same impact.
Consider:
updateTicket()
sendEmail()
issueRefund()
addRole()
createApiToken()
These should not all live behind the same generic "write" permission.
addRole() and createApiToken() can change future authority.
That makes them fundamentally different from ordinary business operations.
IAM changes, credential creation, policy changes, security configuration, and agent delegation deserve stronger boundaries.
Separate Planning From Execution
Agents should be free to reason about high-risk actions without automatically receiving permission to execute them.
For example:
Planner
↓
Proposed Action Graph
↓
Policy Evaluation
↓
Approved Action Graph
↓
Executor
This also improves auditability.
The system can record:
- what the agent proposed,
- what policy allowed,
- what required approval,
- what was denied,
- what actually executed.
That difference matters during incident analysis.
Watch Agent-to-Agent Delegation
Multi-agent systems add another risk.
Customer Agent
↓
Payment Agent
↓
Operations Agent
If calling a more privileged agent effectively gives the caller access to everything the downstream agent can do, privilege can propagate through the agent graph.
Delegation should preserve context such as:
- who started the workflow,
- which agent delegated it,
- which action is requested,
- which resources are in scope,
- whether further delegation is allowed.
Calling another agent should not automatically mean inheriting its authority.
A Practical Example
Consider an operations agent handling failed merchant settlements.
A naive implementation gives it:
ledger.read
merchant.read
settlement.retry
merchant.update
credentials.create
The agent decides that invalid credentials caused the failure.
It creates new credentials, updates the merchant, and retries settlement.
The workflow may succeed technically.
But the model was allowed to rotate security credentials because its own reasoning decided that rotation was necessary.
A stronger architecture lets the agent investigate and propose:
ROTATE_CREDENTIAL
merchant = M1029
reason = authentication_failure
The authorization layer identifies credential rotation as a sensitive operation.
A stronger policy or human approval is applied.
Where supported, execution authority is scoped to that specific merchant and operation, used once, and then expires.
The agent remains autonomous enough to investigate and recommend actions without permanently holding open-ended administrative authority.
The Architectural Goal
AI agents will become more autonomous.
They will interact with more systems, execute longer workflows, and delegate more work.
Their standing authority does not need to expand at the same rate.
An agent can understand how to deploy production software without always possessing production deployment rights.
It can identify an IAM issue without being able to modify IAM.
It can recommend a refund without automatically being able to issue one.
The key question is not only:
Can the agent make the right decision?
It is also:
What happens when it makes the wrong one?
Good agent architecture ensures that a bad decision remains constrained by independent authorization boundaries.
Top comments (0)