Give an agent the smallest useful permission

An agent does not need every permission a person has. It needs the smallest authority that completes the scoped task, plus a clear route to request approval when the task crosses a boundary.

The ladder classifies a specific action, not an entire agent as “safe” or “autonomous.” Reading a customer record, drafting a reply, sending it, and issuing a refund may share one workflow, but each deserves its own level and controls.

Use five levels of authority

Level 1 · Read and explain

The agent can inspect approved data and produce a suggestion. It cannot change external state.

Level 2 · Prepare a reversible draft

It may create a draft, plan, or staged change that a person can inspect before anything is sent or applied.

Level 3 · Execute reversible actions

It may act within explicit limits when the action can be undone and every change is logged.

Level 4 · Request approval for consequential actions

It prepares the action, displays target and impact, and waits for an authorized person to approve that exact operation.

Level 5 · Execute pre-authorized bounded automation

It may perform a narrow consequential action only inside a policy with strong identity, limits, monitoring, and recovery. This is not the default destination for every workflow.

Example: calendar assistant

Reading availability and suggesting three times is Level 1. Drafting an invitation is Level 2. Placing a temporary hold that expires is a reversible Level 3 action. Sending to external guests requires Level 4 approval because it creates a social commitment.

The boundary is attached to the action, not to the label “calendar agent.” One workflow can contain several levels.

Example: cloud cleanup

Listing unattached resources is Level 1. Preparing a deletion plan with cost and owners is Level 2. Adding a reversible quarantine tag may be Level 3. Deleting storage is consequential and should require an exact approval, backup check, and recovery evidence.

Broad administrator credentials do not become appropriate because the final action needs one privileged API.

Define the promotion test

Before increasing authority, require stable evaluation results, complete action logs, scoped credentials, a stop mechanism, and a tested rollback. If one of these is absent, keep the agent at the lower level and let a person complete the handoff.

Inventory actions before configuring tools

List every read, create, update, send, move, delete, and payment action the workflow may attempt. Avoid broad entries such as “access CRM.” Write “read tickets for the selected customer,” “save an unsent draft on this ticket,” or “close an approved duplicate ticket.” Then complete these fields for each action:

Permission field	Question to answer
Target	Which accounts, files, projects, or records are eligible?
Scope	How many objects per action and per time window?
Conditions	Which fields, states, and risk labels must be true?
Credential	Whose identity is used, with which minimal capabilities?
Confirmation	At which level does which person approve this exact action?
Log	Can request, decision, execution, and result be reconstructed?
Undo	How and for how long can the change be recovered?
Stop	Who can revoke the session and queued work immediately?

If target and scope cannot be stated, a broad API is not a substitute for design. The tool boundary should reject out-of-policy requests instead of relying on the model to remember prose in a prompt.

Make approval valid for one exact action

A Level 4 approval view should show the real target, fields to change, irreversible effects, supporting evidence, and preview. Bind the authorization token to an operation digest, approver, expiry, and maximum execution count. Any parameter change requires a new request. A conversational “go ahead” must not become standing permission for future similar actions.

Return the outcome and undo path after execution. When a tool times out and the remote result is unknown, do not retry blindly. Query the idempotency identifier or remote state first.

Design demotion and emergency revocation

Promotion is not permanent. Reduce authority when task scope grows, failure behavior changes, dependencies are revised, an owner leaves, credentials may be exposed, or a recovery drill fails. Keep an independent stop path that can revoke credentials, cancel queues, and reject new actions without requiring the agent to agree.

Exercise at least three conditions: parameters change after approval, a sequence exceeds its quantity cap, and an execution returns an unknown result. The permission design is real only if the system blocks or safely recovers each one.

Common questions

Does human confirmation make an action safe? Not automatically. If the interface hides target and impact, or one click approves an unbounded batch, the reviewer is clicking rather than making an informed decision.

Is read-only access harmless? It still creates privacy, over-broad visibility, and exfiltration risk. Constrain objects, fields, purpose, and retention for reads as well.

When is Level 5 justified? Only after a narrow task repeatedly passes evaluation, the system enforces credentials and quantity limits, abnormal behavior can be stopped, and recovery has been exercised. Saving approval clicks is not enough.

Boundary

Reversibility depends on the real system. “Delete” may be recoverable in one service and permanent in another. Verify the operation, retention window, dependencies, and identity model instead of assigning levels from the verb alone.