What should an AI agent be allowed to do? A practical model
A practical permission model for AI agents: four levels of action from read-only to high-impact, how to enforce them in code rather than prompts, and how to design the handoff to people.
The question we hear most from leadership teams is not whether an agent can do something. It is whether it should be allowed to. That is the right question. Capability is rarely the constraint any more. Trust is, and trust comes from clear, enforced limits.
Start from the cost of being wrong
Every action an agent can take has a failure cost. Reading the wrong document costs a few seconds. Sending the wrong email to a customer costs a relationship. Approving the wrong payment costs money that may not come back. Permission levels should follow those costs, not the convenience of the build.
Four levels of action
- L0Read only
Searching knowledge, reading a record, checking availability. No confirmation needed, but access still follows the user's own permissions.
- L1Write the user's own data
Saving a draft, a note or a contact the user provided. Requires an explicit user interaction, such as pressing save.
- L2External action
Sending an email, booking a meeting, creating a CRM task. Requires the user to confirm the exact action, with the full content visible, before it runs.
- L3High impact
Moving money, changing contracts, deleting records. Reserved for people, or for narrowly scoped systems with approval workflows and a complete audit trail.
Most useful agents live comfortably at L0 and L1, with a small number of carefully designed L2 actions. If a proposed agent needs many L3 actions on day one, the workflow probably needs redesigning before the agent does.
Enforce it in code, not in the prompt
A model requesting a tool call does not grant it authority. The model only proposes. The application decides. That separation is the single most important design decision in any agent.
- Model proposes a tool call
- Check the allow-list
- Validate the arguments
- Check the permission level
- Ask the user if required
- Run and log the result
- An allow-list of tools, with nothing callable that is not on it
- Schema validation of every argument before execution
- Permission checks against the user's own access, not a service account's
- Rate limits and timeouts so a loop cannot run away
- An audit event for every action, with who, what and when
Design the handoff before the automation
Every agent needs a defined route to a person, and that route has to carry the context gathered so far. If the handoff is an afterthought, people stop trusting the agent the first time it gets stuck, because they have to start again from nothing.
- Know when to stop
Define the conditions for handing off: low confidence, a policy boundary, a request for a person, or an action above the agent's level.
- Package the context
Hand over a summary of the request, what the agent found, what it tried and what it recommends.
- Route to the right owner
Send it to the person or queue that owns that decision, not to a generic inbox.
- Close the loop
Record what the person decided, so the rules and evaluations can improve.
Widening an agent's remit safely
Permissions are not set once. Start narrow, measure, and widen only on evidence. A common progression is to run an action in suggestion mode first, where the agent drafts and a person executes, then move to confirmation mode, then to automatic execution for the low-risk cases the logs show it handles reliably.
An agent is a digital operator with a job description, a permission set and a manager. Not a chatbot.
Frequently asked questions
How should AI agent permissions be enforced?
In code. The application should check every tool call against an allow-list, validate arguments, require confirmation for external actions and log the result. A prompt instruction alone is not a security control.
What actions should an AI agent never take on its own?
High-impact actions such as moving money, changing contracts, deleting records or making commitments to customers should stay with people, or with tightly scoped systems that have approval workflows and an audit trail.
What is prompt injection and why does it matter for agents?
Prompt injection is when text in a document, email or web page contains instructions the model might follow. For an agent that can take actions, it means retrieved content must never be treated as permission to act.
How do you decide an agent's permission level?
Ask what happens if the agent is wrong. The higher and less reversible the cost of a mistake, the higher the level and the stronger the confirmation required.
Get the next note by email
One email a month at most. Practical, from real work. Unsubscribe in one click.