What Authority Should an AI Agent Act With?
The authority of the specific human who made the request, for the duration of that request, and no more. Not the agent's own standing credentials, not the union of what everyone in the workspace can do, and not whatever authority the content it just read implies it should have.
That single rule closes most of the interesting failure modes. What it does not close is the question of proof, which is why the second half of this comes down to audit: a record of what was decided and why, including every request that was refused.
I'm Mahmoud Zalt, an AI architect. At Sistava I build agents that take real actions inside companies, which means this is the layer I lose sleep over rather than the layer I theorise about.
This closes a three-part series. Part one: why prompts are not permissions. Part two: access control inside the retrieval layer. Solving those two solves the reversible half of the problem. This is the half that sends, publishes, pays and deletes.
The Confused Deputy, Now With a Natural Language Interface
An AI agent handles inbound support. It reads tickets, looks up customers, and issues refunds under a threshold. Ordinary, useful, the reason people buy these products.
A ticket arrives. Somewhere past the polite opening, a paragraph is addressed to the machine rather than to the human: instructions about a different account, an urgent internal request, a plausible reason to export a list or approve something.
The model reads it. The model is helpful. The model calls a tool.
This is the confused deputy problem, and it is as old as computing. A component holding legitimate authority gets manipulated by someone without that authority into using it on their behalf.
What is new is the delivery. The manipulating input arrives as ordinary business content, in natural language, through the front door, and the deputy is a system explicitly designed to follow instructions found in text.
You do not solve this by making the model more suspicious. Suspicion is not a permission boundary. You solve it by making the agent's authority to act smaller than the damage it could plausibly be talked into.
Content Is Data, Never Instruction
Text the agent reads, from a ticket, a document, a webpage, a connected inbox, an integration payload, can influence what the agent proposes. It must never expand what the agent is permitted to do.
Authority comes from the execution identity established at the start of the request, before any content was read. Nothing read afterwards can raise it. If retrieved content can affect the permission decision anywhere in your architecture, then the permission decision does not exist, it is just a suggestion with better formatting.
The practical implication is that permission state and conversation state must be separate stores with a one-way relationship. The conversation can read the permission state. The permission state never reads the conversation.
This sits underneath the injection mitigations covered in how to add guardrails to production AI agents. Guardrails reduce how often a bad call gets proposed. Authority limits decide what happens when one gets through, and one always eventually gets through.
Revalidate at the Call, Not at the Plan
An agent produces a plan, then executes it, sometimes across several steps and several minutes.
Authorising the plan authorises an intention. What actually reaches your systems is a specific call with specific arguments. That call is what gets checked, server-side, against the requester's authority, the target resource's policy and the tool's own grant.
Every time. Including the retries. Including the steps the model added mid-run because it thought of something helpful. Including the second call in a loop that looks identical to the first but points at a different record.
The failure mode here is subtle and common: teams check permissions when the agent is planning, because that is where the reasoning is legible, and then trust the executor. The executor is the only part an attacker can reach.
Sort Tools by Blast Radius, Not by Category
Flattening every tool into a single permission is how products end up either uselessly restrictive or quietly dangerous. The tiers worth distinguishing:
tier 1 read reversible, internal, no external side effect
tier 2 write reversible, internal, recorded, undoable
tier 3 external irreversible or visible outside the workspace:
send, publish, pay, delete, share externally,
connect a new integration, export data outTier 3 is where autonomy stops being a feature and starts being a liability. That is where human approval belongs.
Not on everything. Approval fatigue turns into reflexive clicking, which is genuinely worse than no approval at all, because it manufactures a signed record of a decision nobody made. Gate the things that cannot be taken back, and let the rest run. The mechanics of confirmation gates and least-privilege tool scopes are covered in guardrails and permissions for AI agents that take real actions.
Approvals Are Objects, Not Dialogs
If approval is a modal that returns true, you have built a speed bump.
An approval should be a first-class record, and its properties are what make it meaningful:
requested_by the agent run, with its full context
approver the human principal, with authority to grant this
scope this exact action, these exact arguments
single_use yes
expires_at short
decision granted | denied, with reasonScoped to the specific action and arguments, so a grant to send one message is not a grant to send a hundred.
Single use, so a plan that loops cannot redeem the same approval twice.
Expiring, so an approval given in one context cannot be spent in a different one an hour later.
Attributable, so the record outlives the conversation that produced it.
Anything looser and you have permanently delegated authority to the agent while telling yourself you approved one thing.
Your Audit Log Should Record the Denials
Most audit logs answer one question: what happened?
The useful ones answer a different question: what was decided, and why?
That means logging the policy decision itself, not just its successful outcomes. Who requested, what was requested, which policy applied, which version of that policy, what the outcome was, and critically, the requests that were refused.
Denials are the highest-signal events in the entire system, and almost nobody keeps them.
A spike in denials means one of three things: an agent doing something it should not, a permission model that is wrong, or someone probing. All three are things you want to discover on a dashboard rather than in a customer's incident report. Successful actions tell you your system worked. Denied actions tell you what it is being asked to do.
And when a customer's security team eventually asks whether enforcement is real, the decision log is the only answer that is not merely an assertion. Compliance is the least interesting reason to build it.
What Belongs in an Agent Decision Log
| Field | Why it matters |
|---|---|
| Requester principal | Whose authority was borrowed. Without it you cannot reconstruct whether the action was legitimate. |
| Agent run id | Ties scattered tool calls back to one intent, so you can see the sequence rather than the events. |
| Tool and arguments | The actual call, not the plan. Redact payload contents, keep the shape. |
| Target resource | What was touched, including records that were read and not changed. |
| Policy and version | Lets you answer whether behaviour changed or the rules did. |
| Decision and reason | Granted or denied, and which check failed. A denial with no reason is a mystery you will inherit later. |
| Approval reference | Links a tier 3 action to the human who signed for it. |
Two habits make this pay off. Log denials at the same fidelity as successes rather than dropping them at warning level. And make the log immutable and separately readable, so investigating an incident does not require the same access that caused it.
Frequently Asked Questions
How do you stop prompt injection from triggering unauthorised tool calls?
Separate influence from authority. Injected text can change what the agent proposes but must never change what it is permitted to execute. Enforce permissions server-side on every individual tool call, against the identity established before any content was read.
Should every AI agent action require human approval?
No. Approval fatigue produces reflexive clicking, which is worse than no gate because it creates a signed record of a decision nobody actually made. Tier actions by blast radius and gate only the irreversible or externally visible ones.
What should an AI agent audit log contain?
The decision, not just the action: requester, agent run, tool and arguments, resource, policy applied and its version, outcome, timestamp, and every denial. Denials are the events that tell you something is wrong before a customer does.
Is it safe to let an agent reuse an approval across steps?
No. Approvals should be scoped to specific arguments, single use and short-lived. A reusable approval is a permanent delegation of authority wearing the costume of a one-time decision.
Can an agent have more authority than the person who asked it to act?
It should not, in the general case. Where a workflow genuinely requires it, such as an agent reading a system table an ordinary member cannot, that elevation should be a narrow, named, logged capability rather than a property of the agent's default identity.
Three Things to Take Away
One. The agent borrows the requester's authority and hands it back. Content it reads along the way can change what it suggests, never what it is allowed to do.
Two. Check at the call, not at the plan, and gate by blast radius so approvals stay meaningful instead of becoming muscle memory.
Three. Log decisions rather than outcomes, and keep the denials. They are the only early warning you get.
That closes the series. Part one covered the four checks every sensitive operation should pass, part two covered provenance and retrieval-time filtering, and this one covered what happens at the moment of action. The industry spent two years making agents more capable. The next stretch is about making that capability accountable, and I do not think anyone sells into a serious company without it.
