AI Agent Permissions: The Ladder From Read to Act

Reading a document is different from changing it. Drafting a refund message is different from issuing the refund. Comparing vendors is different from signing a contract.

An agent’s permissions determine what it can access and what it can cause to happen. A useful starting point is a ladder from reading to acting, with review and limits matched to the job. The ladder is a planning aid, not a universal ranking of risk: reading a sensitive medical record can be more consequential than editing a disposable test file, and a draft can still expose private information.

The permission ladder

Use these stages to discuss how much authority a particular workflow needs:

1. Read: Inspect the approved files, pages, records, or tickets needed for the task.
2. Draft: Prepare proposed text, code, plans, or messages without sending or publishing them.
3. Edit with a recovery path: Change controlled material where the previous state can be restored and the effects are understood.
4. Submit for approval: Prepare a specific action for an authorized person to review before execution.
5. Act within limits: Perform defined actions under a policy with clear thresholds and exception handling.
6. Act autonomously with audit: Handle a bounded class of routine work, with monitoring, review, and a way to stop the workflow.

These stages can overlap. An agent might read selected customer records and draft replies while a separate service executes an approved refund. Logging and review belong at every stage where they are needed, not only at the top. A workflow does not need to reach autonomous action; for some tasks, draft-only is the right endpoint.

Start with the minimum access needed for the job, then expand only when the owner can explain the need and verify the controls. This is the principle of least privilege . The capability inventory can help identify what the agent and its tools can actually do.

Write down the grant

A ladder stage describes the kind of work, but it does not specify the boundary. For each workflow, record the identity, approved task, data and actions, target environment, restrictions, owner, and expiry or review date. Include where the restriction is enforced. For example:

This is a design example, not a guarantee that a particular product supports case-scoped access. Verify the effective permissions in the actual systems. If the service can only grant access to every customer record, document that wider access and decide whether the workflow can be made safe enough to use; do not describe it as case-scoped because the prompt says to use one case.

The three questions before granting action

Is the action reversible? Renaming a draft file is different from deleting a customer record. Reversibility is social as well as technical: cancelling a calendar invite does not erase the confusion it caused. Check whether a backup exists, whether it can be restored, and whether downstream notifications or exports can be undone.

Does the action touch sensitive data? Customer information, medical details, financial records, employment data, credentials, legal documents, and personal messages deserve careful limits on access and disclosure. Read access can itself expose data to the model provider, a log, an output, or another tool. Give the agent only the fields and destinations the task needs; see data boundaries and redaction .

Does the action create an obligation? Money movement, purchases, refunds, contracts, policy promises, hiring decisions, and messages sent under a person’s name can have effects beyond the system. Set explicit approval or policy controls appropriate to the consequence. A technically reversible transaction may still require reconciliation or a difficult conversation.

Make the boundary enforceable

A permission is more than an instruction in a prompt. Configure the account, tool, and destination system so that an agent cannot perform an out-of-scope action through another route. A support drafting agent, for example, can use a restricted identity that reads selected ticket fields and policy documents but cannot call the refund API. Separate test and production access, and check inherited roles, browser sessions, and integrations as well as the tool’s advertised functions.

Treat material the agent reads, including tickets, webpages, and tool results, as data rather than authority to widen access. A malicious document might instruct the agent to send private records elsewhere. OWASP’s prompt-injection guidance recommends enforcing tool permissions and validating arguments outside the model; filtering or asking the model to ignore malicious instructions is not a complete control.

Test the boundary with synthetic data and a safe test account or non-destructive permission check. Confirm that an allowed read and draft succeed, a different customer’s record is denied, a refund cannot run without valid approval, and an unapproved destination cannot receive the test data. Check tool calls and destination state as well as the agent’s final response: a refusal after an action does not undo it. Record the identity, environment, paths tested, and results. A denied probe demonstrates that particular path was blocked, not that every route is closed. The sandbox guide covers safer test environments.

If a required restriction cannot be enforced or verified, narrow the workflow, use a different execution path, or keep the action with a person. If the approval service or policy check is unavailable, the execution path should stop rather than treat the missing decision as permission.

Approval gates should be specific

“Ask before doing anything important” leaves too much to interpretation. A policy can instead say:

• Ask before sending an external message or editing a published page.
• Ask before changing permissions or credentials.
• Ask before deleting, archiving, or overwriting a production record.
• Ask before a purchase above a stated amount and currency, including any applicable cumulative limit.
• Pause before accessing a source outside the approved scope; do not assume that approval to use a source also permits sharing its contents.

For an approval, show the reviewer the action, target, environment, material details, evidence, and expected effect. Record who approved it, the approved version, expiry, and whether it permits one execution. The execution path should check those conditions and relevant current state immediately before acting; a changed target or payload may need new approval. OWASP’s transaction authorization guidance explains why significant transaction details and the final authorization check belong together. The companion guide on approval scopes covers expiry, changes, and retries in more detail.

A customer refund example

A support team can apply the ladder to one refund workflow:

• The agent reads the ticket, the relevant order fields, and the current refund policy, then drafts a response and recommendation.
• It prepares a proposal containing the order identifier, amount and currency, original payment method, reason, policy version, and customer message. Preparing a form is not necessarily harmless: verify that it does not save, notify, or submit anything before treating it as a draft.
• An authorized reviewer approves the specific refund. The execution service checks that the order is still eligible and unrefunded, the approval is valid, and the action matches what was reviewed.
• For a later, bounded policy route, the team might allow eligible refunds under $20 without individual approval. The amount is an example, not a recommended limit. The policy must define currency, eligibility, cumulative limits, exceptions, ownership, monitoring, and when to stop the route.

If a limit applies across multiple refunds, the executor must account for simultaneous requests as well as completed ones; checking each request in isolation can let the total exceed the limit. Where the system supports it, reserve the allowance and consume a one-use approval atomically. Otherwise, use a controlled queue or another process that prevents concurrent execution from bypassing the limit.

If the refund request times out, its outcome may be unknown. Check the payment system for the original action or use its supported idempotency mechanism before retrying. If a duplicate cannot be ruled out or prevented, pause and escalate. A refund approval does not automatically authorize sending the customer message. Retries and idempotency explains how to handle uncertain outcomes.

Logs are not optional

If an agent acts, it should leave a trail that an authorized operator can inspect. Record the goal or task identifier, sources and tools used, proposed and executed actions, targets, approval references, timestamps, outcomes, and failures. Capture the policy or decision reason where available, but do not rely on a model’s explanation as proof that an action was authorized or actually completed.

Logs can also expose private information. Avoid credentials and unnecessary customer content; use restricted evidence references where possible. Set access, retention, and deletion rules, and check that logging covers the execution path. A useful trail helps a team diagnose a mistake without creating a second uncontrolled copy of the data. See observability and traces for the operational details.

The permission review

Permissions should expire where practical, and remaining access should be reviewed on a schedule suited to the risk and after a meaningful change. Tools gain capabilities, policies change, and owners leave. A grant that fit a pilot may be too broad after new systems are connected.

1. Identify the agent, its owner, and its current task.
2. List the identities, tools, data sources, environments, and inherited access it can use.
3. Compare each read and action permission, including approval paths, with the work it still needs to do.
4. Retain, narrow, or remove each grant; give any exception an owner and expiry.
5. Verify the effective access after changes and record unresolved gaps and the next review date.

Include a way to stop active runs and revoke access. Revoking a credential may not immediately end every token or browser session, so check the system’s behavior and confirm denial. The access review guide walks through the evidence and ownership needed for this review.

The real goal

Permission design makes an agent’s authority understandable and enforceable. Choose one workflow, write down what it needs to read and do, and identify the first action that needs a gate. Then test the allowed and denied paths before expanding its authority. A clear lane lets the agent do useful work while people retain control over consequential decisions.