Field note
AI Agent Approvals vs Permissions
Separate what the agent is allowed to do from what a person must approve for this specific action.
Separate what the agent is allowed to do from what a person must approve for this specific action.
Why an approval prompt is not a permission model
An approval prompt asks a person "should the agent do this now?" A permission decides whether the agent can do it at all. Teams often connect an agent with broad access to email, files or a finance system, add an "Are you sure?" step, and treat that step as the control. It is not. If the agent holds a credential that can delete records, the only thing between a bad instruction and a deleted record is a person clicking the right button, every time, under time pressure.
Permissions are the outer boundary. Approval sits inside that boundary and handles the cases where a person must use judgement. Design the boundary first, then decide where approval belongs.
Permissions: what the agent can ever do
Start with a short table, one row per connected system. For each row, record the data the agent can read, the actions it can take, the identity it uses and who can revoke it. Then cut the list until every entry is justified by a task the agent actually performs.
Three checks matter most:
- Reads and writes are separate decisions. An agent that drafts customer replies needs to read the ticket. It does not need permission to send.
- The enforcement point is your code or the platform, not the model. With OpenAI function calling and Anthropic tool use, the model only requests a call; your application decides whether to run it. That is where a deny rule belongs.
- Deny lists must be tested. In Claude Code, permission rules can allow, ask or deny specific tools and commands, and a deny rule wins. If you rely on a rule like that, run a test that tries the blocked action and confirm it fails.
A useful habit is to give the agent a dedicated account with its own licence and its own logs, never a shared login. When the account is disabled, the agent stops. Nothing else should.
Approval: what a person must decide
Approval is for consequential actions where the right answer depends on context the rules cannot capture. Paying a supplier whose bank details changed last week. Sending a message to a customer with a complaint history. Granting a new user access to a shared drive.
For approval to mean anything, the person needs to be able to decide. The prompt must show the target record, the exact arguments, the source of the instruction and a plain-English summary. "Update customer" is not enough. "Change the billing address for account 4471 from the one on the July invoice to the one in today's email from an unverified sender" is a decision someone can make.
Keep approvals single-use, time-limited and logged with the approver's name. An approval given at 09:00 should not authorise a retry at 17:00 with different arguments.
Watch for approval fatigue
If one person is asked to approve forty actions a day, they will approve everything. That is not a training problem. It is a design problem: too many actions are reaching approval because the permission set is too wide or the rules are too vague.
Fix it by narrowing. Let deterministic rules handle the clear cases (an invoice that matches a purchase order within tolerance can be posted without a prompt). Send only the genuine exceptions to a person, and make the reason for the exception visible in the prompt.
A worked example
Take a 25-person building supplies firm that lets an agent process supplier invoices. The wrong design gives the agent full access to the accounting system and asks the finance manager to approve each payment run. The finance manager approves quickly because the runs look normal, and one day a fraudulent "updated bank details" email has been acted on.
The better design gives the agent read access to invoices and purchase orders, write access only to a draft payment batch, and no permission to edit supplier records at all. Bank detail changes cannot happen through the agent. The finance manager approves the batch, and the prompt highlights any supplier whose details differ from the last paid invoice. The permission model removed a whole class of failure. Approval handled the rest.
Verify after the action
Approval before an action is not proof that the action was correct. After the agent runs, check the result against what was approved: the record changed, the amount, the recipient. Log both the approval and the outcome so an auditor can pair them.
The agentic AI security checklist covers the wider access matrix and failure playbook. If you want the permission and approval design written into a control set the business can maintain, an AI governance review is the place to start.
What to write into policy
- Every agent has a named owner and a dedicated identity.
- Permissions are documented per system and reviewed when a task changes.
- Approval is required for a listed set of action types, with the list owned by a named person.
- Approval prompts must show target, arguments and instruction source.
- Approvals are logged with approver, time and outcome.
- Anyone can pause an agent; only the owner can widen its permissions.