Blanket permission is the default because nobody wrote the alternatives
Most enterprises have already answered the agent permission question, usually without a decision. The answer is that agents can do whatever the human credential they run under can do. A service account with broad read and write access is granted to an assistant, a colleague is told to check its output, and the arrangement is described internally as supervised. Nothing supervises it at scale, because supervision at scale requires a queue of people to read.
The remedy is not to deny agents access. It is to replace a general permission with a specific one: an enumerated set of actions, on named data, within stated limits, each of which is either reversible, approved, or explicitly recorded.
Least privilege for an agent means fewer systems, not shorter prompts
The instruction that governs an agent's behaviour is not the prompt. It is the set of tools it can reach and the credentials those tools carry. A well-worded instruction to be careful does not prevent a call to a write endpoint, and it is not auditable. The permission is the control, and it has to be enforced where the action happens.
In practice this means three separations. Give the agent read access to the records it needs for context and none to the systems holding unrelated material. Give it a separate, narrow write credential for the one workflow it participates in. And give it a distinct identity, so every action it takes is attributable to the agent.
The task boundary is the unit of permission, not the system
Permissions expressed per system tend to be either everything or nothing, because a system is a large unit. The useful unit is the task. An agent that handles supplier price amendments is doing a different thing from one that answers questions about supplier performance, even though both read the same table.
Writing the boundary in task terms forces the useful questions. What does this task legitimately need to read? What is the smallest set of fields that makes it workable? What must it never see, and why is that different from what it never needs? A boundary drawn this way also survives change: when the task is extended, the permission is reviewed as part of the same change.
Human authorization is a design choice with a running cost
Authorization is not free, and treating it as a free safety net is how approvals become noise. Each confirmation consumes attention from someone with real work to do, and a queue that everything passes through is a queue everybody learns to approve quickly. The design choices are about where human judgement enters: which specific decisions require a person, what they are shown, and what happens to the work while the case is waiting.
A useful split separates the agent's role into three parts. It prepares, it proposes, and it commits. Preparation and proposal can run unattended. Commitment, where the action affects the outside world or moves value, should require a person, and the number of such actions should be small enough that approvers can read them properly. The mechanics of that split are in designing AI workflows with human approval and exception handling.
Limits are more usable when they are stated as quantities
A limit expressed as a quantity is one an approver can recognise and a system can enforce. A maximum value per action, a maximum number of actions in a period, a maximum number of records changed before a human is required, a maximum age of the data the agent may act on. Each is checkable, and each produces a clean refusal that can be logged.
| Permission layer | What the agent may do | What must be recorded |
|---|---|---|
| Read and draft | Read named sources, summarise, prepare a proposal | Sources accessed, proposal produced, no external effect |
| Act within limits | Take defined actions below stated thresholds | Action, inputs, values, and the limit checked against |
| Act with confirmation | Take defined actions above a threshold after approval | The same record, plus who approved and when |
| Escalate | Stop, explain and hand the case to a named owner | Reason, state at handover, and the clock on the case |
The thresholds should be set by the business rather than by the engineering team, and set conservatively at first. A limit that is too low costs a little of the agent's usefulness; a limit set too high creates an exposure discovered after the fact.
Every action needs a record that survives the system
An agent's audit trail is not optional instrumentation; it is what makes the permission scheme reviewable. For each action the record needs the identity the agent acted as, the time, the inputs used, the decision made, the value involved, the permission that allowed it, and where a person confirmed it. Where the action was refused, the refusal and its reason matter as much as the successes.
The record should be written somewhere the agent cannot edit and that outlives the workflow it describes. Logs held inside the same application, in a format that changes when the application is rebuilt, are not evidence of anything. This is the reasoning in building auditability into AI-enabled business processes.
A sequence for the first agent you deploy
- Write down, in one sentence each, the decisions the agent will prepare, propose and commit to, and mark the commit list as the risky one.
- Enumerate the data the agent needs for those decisions and nothing else, and give it a distinct identity with a narrow write credential.
- Set one limit per action type, with a number attached, and decide who sets the number and who reviews it.
- Define the approval path for anything above a limit, including what the agent does while the case is waiting.
- Decide where the action record will live, in what form, and how long it is kept.
- Review the refusal rate, the approval rate and the exception volume after a fixed period, treating a boundary that never triggers as untested.
The measures that tell you the boundary is real are the proportion of actions that stayed inside their limits, the number of approvals returned unchanged, the number of cases that escalated, and the number of permissions widened after launch. The engineering that keeps such permissions enforceable is in enterprise agent engineering.
Where this approach stops working
The scheme above assumes the actions can be enumerated, that the underlying data has stable definitions, and that somebody can decide the thresholds. Where tasks are open-ended and the actions are not knowable in advance, an enumerated permission list becomes fiction. The honest response is then to keep the agent on the preparation and proposal layers only.