# AI Agent Permissions and Controls: How to Design Them Step by Step

> How to design AI agent permissions and controls: read, write and forbidden access, spend and action limits, human approvals, and revocation.

- Canonical: https://arkatai.com/en/ai-agent-permissions-controls/
- Site: Arkatai (https://arkatai.com) — agentic operations as a service
- Language: en
- Published: 2026-07-19

---


You design an AI agent's permissions and controls before it handles a single real case, and you design them the way you grant authority to a new employee: access to only what the job needs, limits on what it can commit, and a fast way to take it all back. In practice that is five concrete decisions: what it may read and write, how far in value or volume it can go alone, what requires a person's signature, and how you revoke its access. This is the order I work through when preparing a deployment.

## Step 1: inventory what the agent needs to touch

Before granting anything, write the list of systems the process touches and sort each one into three columns: read, write, forbidden. An agent that matches invoices needs to read orders and delivery notes, write to the reconciliation record, and is forbidden from issuing payments. The discipline is that the forbidden column must not sit empty by default: anything not justified by the function goes there.

| System | Reconciliation agent's access |
|---|---|
| Orders and delivery notes | Read |
| Reconciliation record | Write |
| Payment issuance | Forbidden |
| Payroll and HR | Forbidden |
| Outbound supplier email | Write with approval |

This inventory is also the map of your risk surface. Every write permission and every read access to sensitive data is a path along which an error or an attack can spread, which is why it is worth reviewing alongside [an agent's security threats](/en/ai-agent-security/), because excessive permission is what turns a small fault into an expensive one.

## Step 2: give it its own identity and least privilege

Wiring the agent to a person's account is the fastest option and the worst. It inherits every permission of that account, and the systems record its actions as if they were the employee's, so you lose the ability to tell who did what. Give it its own credentials, scoped to the process it operates. The rule is read where reading is enough and write only where writing is its job, applied more strictly than you would to a person, because with an agent you can do it precisely and verifiably.

Start narrow and widen with evidence. It is cheaper to grant one more permission when the process asks for it than to withdraw one that never should have existed after an incident.

## Step 3: set action and spend limits

Permissions say what the agent may touch. Limits say how far it can go alone. This is the layer most deployments skip, and the first one a CFO asks about. Four types cover almost everything:

- **Per-operation cap.** The maximum value of a single action without intervention: a payment amount, a discount, a price adjustment.
- **Cumulative cap.** The maximum per period, so many small actions cannot add up to a large problem unseen.
- **Rate limit.** How many actions per unit of time. An agent can repeat the same error hundreds of times before a person notices, and the rate limit bounds how many cases it affects before a review triggers.
- **Exception thresholds.** Conditions that, once met, pull the case out of the automatic flow: a new customer, a deviation from contract terms, a missing field.

The criterion for setting each number is reversibility. What is cheap to undo tolerates a high cap. What cannot be undone is capped short or forbidden. Imagine a distributor doing 80 million whose agent issues credit notes: a low per-operation cap, a daily cumulative cap, and human sign-off for any customer outside the usual book keep the damage of an error to a figure the board can tolerate.

## Step 4: define what requires human approval

Escalation to a person is part of the spec from day one, not a patch added after a scare. The question is which actions should never run without someone looking. My starting list is the irreversible ones and the ones that commit the company to a third party: sending money, deleting records, making a commitment to a customer, onboarding a new supplier. Those go with a signature until evidence justifies otherwise.

For the rest, review need not be case by case. Reviewing everything removes much of the benefit, and reviewing nothing leaves model error unchecked. In between sits sampling, at a rate adjusted from observed failures. Where to place that line and how to prepare the case for whoever reviews it is what I cover in [exception handling and human escalation](/en/exception-handling-ai-agents/), and it fits the general [human-in-the-loop](/en/human-in-the-loop/) pattern.

## Step 5: prepare revocation and review

A permission with no expiry tends to stay forever. Every grant should carry a review condition: when you check whether it is still needed, and by what criterion you widen or withdraw it. And every agent needs an immediate way to cut its access, a switch a business owner can pull without calling an engineer, for the day something goes wrong and you have to stop it before you understand why.

Autonomy is earned with a track record, just as it is with people. When months of records show a class of cases resolving well, the limit widens, and when a new class of error appears, it contracts. That requires the record to exist and be readable, which is exactly what connects this work to [auditing the agent's decisions](/en/auditing-ai-agent-decisions/): without a trace you cannot justify any widening of permissions.

## How it fits with security and governance

These five steps are the operational design of the limits. Why those limits matter is explained by [an agent's specific threats](/en/ai-agent-security/). How you prove they were respected is explained by [auditing its decisions](/en/auditing-ai-agent-decisions/). And the framework that decides who sets risk appetite and who is accountable is [AI agent governance](/en/ai-agent-governance/). Designing permissions from the start, rather than after the first incident, is what lets you widen the agent's scope without rebuilding the architecture, and it is part of what I review when [preparing a company for agents](/en/prepare-your-company-for-agents/). The full context of what an agent executes and with what guarantees is in [AI agents for business](/en/ai-agents-for-business/).

## Frequently Asked Questions

### What is the difference between a permission and a control?

A permission says which systems the agent may touch and in what mode: read, write, or nothing. A control says how far it can go within what is permitted: an amount cap, a rate limit, an action that requires a human signature. The permission defines the surface. The control defines the depth. You need both.

### Can the agent use an employee's credentials to move faster?

It can, but that is the decision that concentrates the most problems. The agent inherits all of that person's permissions, including those unrelated to its task, and the systems stop distinguishing its actions from the employee's. Giving it its own identity costs a bit more upfront and returns least privilege and traceability, which are the basis of everything else.

### How much autonomy is reasonable at the start?

Little, and growing. At first the agent should work in read or proposal mode for anything with external consequences, with irreversible actions going through a person. Autonomy widens by classes of cases when the record shows an acceptable error rate, with each permission tied to a date and a review condition.

### Do I need technical staff to manage permissions day to day?

It depends on the model. If you build or buy the platform, someone in your organization maintains identities, limits, and reviews. If you contract a managed operation, the provider maintains that mechanism while your team keeps the authority to set the limits and pull the revocation switch. What should never happen is that nobody knows who can stop it.