Give agents permissions in steps, not all at once
Giving an agent one broad permission setting makes routine work either risky or frustrating. A permission gradient ties each action to its impact, reversibility, and evidence.
On this page 5 sections
- Set permissions per action, not per agent session.
- Increase scrutiny with impact and irreversibility.
- Make approval requests show the exact action and its evidence.
An agent that can only observe is safe but limited. An agent that can do everything is capable until it makes one consequential mistake. The product problem is not choosing between those extremes; it is deciding which actions can happen automatically, which need a check, and which should remain outside the agent’s authority.
Permission is a product decision#
A single “autonomous” toggle hides several distinct capabilities. Reading a record, drafting a reply, sending that reply, and changing an account are not equivalent just because they appear in one workflow. Their consequences differ, and so should the permission model.
I would start by describing each action along three dimensions:
- Impact: How much harm or disruption could a mistake cause?
- Reversibility: Can the action be undone completely and cheaply?
- Evidence: Can a person or system inspect why the agent chose it?
These dimensions are not a scoring formula that magically determines policy. They are prompts for a product decision. A low-impact, reversible action with clear evidence may be a reasonable candidate for automatic execution. A high-impact action that is difficult to reverse should require explicit authorization, even when the agent’s confidence is high.
For example, in a hypothetical support workflow, categorizing a message could be automatic. Drafting a response could be automatic but remain unsent. Sending a response might require approval when it contains a commitment or handles a sensitive case. Issuing a refund could be restricted to an authorized person. The important distinction is not “AI versus human.” It is what the action does and what recourse exists if it is wrong.
Use a ladder, not a toggle#
A practical permission gradient might have four levels:
| Level | Agent may | Typical control |
|---|---|---|
| Observe | Read approved context and summarize | Scope access to relevant records |
| Prepare | Draft, classify, or propose a change | Keep the result as a draft |
| Execute reversible actions | Make changes with a clear undo path | Log the action and expose undo |
| Execute consequential actions | Commit external, financial, or hard-to-reverse changes | Require an authorized confirmation |
This ladder is a starting point, not a universal taxonomy. Some “reversible” actions are expensive to repair; some seemingly minor actions expose private information. The product team should classify the actual domain action, not trust a label such as update or send to explain its risk.
The levels should also be assigned per action, not per agent. A workflow may allow an agent to organize files while requiring approval before sharing them. If the user has to grant broad access to get one useful capability, the product is asking them to accept unnecessary risk.
Make confirmation informative#
A confirmation dialog that says “Allow agent to continue?” transfers the decision to the user without giving them enough information to make it. A useful approval request should answer four questions:
- What will happen? Name the action in ordinary language.
- To what or whom? Identify the target and affected parties.
- Why now? Show the relevant evidence or condition that triggered it.
- What happens after approval? State whether the action is reversible and how to recover.
Imagine a proposed change to a customer record. “Update record” is not enough. The request should identify the field, old and proposed values, the source of the proposed value, and whether the change can be undone. If the agent cannot show its source, that is a reason to ask for more review, not a reason to produce a more confident-sounding prompt.
Approval should be scoped as narrowly as possible. Approving one named action should not silently authorize similar future actions. If repeated approvals become burdensome, the product can offer a bounded rule: for example, permit a defined action for a specified set of records, within a limit, for a stated period. The user should be able to inspect and revoke that rule.
Treat automation as something earned#
A common design mistake is to begin with broad autonomy and add confirmation after users discover failures. A safer sequence is to start with observation and preparation, then expand authority only when the action boundary and recovery path are understood.
That does not mean every action needs a human in the loop forever. It means each step up the ladder should answer a concrete question. What failure could occur? Who would notice? How quickly? Can it be reversed? What evidence would tell us that the action is safe enough to automate in this context?
A product team can write a short policy for each action:
Action: [specific operation]
Automatic when: [bounded conditions]
Approval required when: [risk or uncertainty]
Evidence shown: [inputs and rationale]
Recovery: [undo, escalation, or remediation]
For instance, a team might permit automatic categorization only when the record is in a defined queue, keep proposed edits as drafts, and require an authorized person to approve an external commitment. The policy is specific enough to test and revise. “The agent can handle routine cases” is not: different people will disagree about what routine means.
Measure the boundary, not just task completion#
If a workflow reports only whether the agent completed its task, it may reward unsafe behavior. A more useful review asks whether the agent stayed within its authority, whether approval requests were necessary and understandable, and whether a person could recover from a mistaken action.
For a sample of actions, inspect:
- Was the action permitted under the policy in force?
- Did the agent present the evidence needed to justify it?
- Did it stop when a condition was outside its authority?
- Could the affected user identify and reverse an error?
These are review questions, not claims that one metric can prove safety. A team can use them to find vague policies, missing controls, and approval steps that have become rote clicks. If people repeatedly approve without reading, the response should not automatically be to remove the check; first determine whether the request is poorly designed or the action is genuinely low-risk and can be bounded more tightly.
The decision rule I would take into a design review is simple: grant the least authority that still makes the workflow useful, and make every increase in authority conditional on a clear boundary, inspectable evidence, and a credible recovery path. If any one of those is missing, keep the action at the draft or approval stage.