AI agent permissions: how users grant, limit and revoke what an agent can do

A SaaS product should let users hand authority to an AI agent in four separate acts: grant it a small, named set of actions; scope those actions to specific records; limit them by money, volume, time and rate; and revoke them in one step that stops work already under way. Autonomy should then rise one rung at a time, from suggesting to acting, only when the agent's own record shows it uses what it has been given well, and it should drop again the moment that record breaks.

That is the end user's side of agent delegation. The identity layer underneath has moved quickly this year, and it now settles most of the plumbing. What it does not settle is the screen where a person decides what this agent may do for them, for how long, and how they take it back.

What the identity standards settle, and what they leave to your product

Three developments define the plumbing in late 2026.

• Agents have identities of their own. Okta made Agent SSO generally available on 24 August 2026. It is built on the open Cross App Access standard, registers each agent in Universal Directory and issues short-lived tokens in place of stored credentials. Microsoft Entra Agent ID gives agents their own identities too, and supports both autonomous access and delegated access, where the agent acts on behalf of a signed-in user with rights that user holds.
• The Model Context Protocol hardened authorisation. The MCP specification of 28 July 2026 builds on OAuth 2.1, asks clients to request only the scopes they need, and defines step-up: a server that needs more answers with a 403 insufficient_scope error naming the scopes required, and the client asks again for the old scopes plus the new ones.
• Delegation is distinct from impersonation. RFC 8693, OAuth 2.0 Token Exchange, draws the line: under delegation the acting party keeps its own identity and is recorded as the actor; under impersonation it becomes the user.

Notice where consent has gone. Okta's Cross App Access documentation describes access granted between apps without extra consent prompts, with the connection managed by IT. Microsoft's on-behalf-of guide says users cannot grant consent interactively to child agent identities; an administrator pre-authorises the permissions instead. That is good for enterprise control, and it is covered by the customer's admin console, which we set out in our admin console checklist. But it means the identity provider's consent screen is no longer where the end user learns what the agent may do. Your product is.

The risk if nobody designs that moment has a name. OWASP's LLM06:2025 Excessive Agency traces damaging agent actions to three root causes: excessive functionality, excessive permissions and excessive autonomy. The first two are what a grant controls. The third is what an autonomy ladder controls.

Four separate acts: grant, scope, limit, revoke

It is tempting to fold these into one "Connect" button. Keep them apart, because each answers a different question the user has.

A grant without scope is "edit anything I can edit", which is how an agent inherits a user's whole account. A scope without limits lets a correct action run a thousand times. A revoke that only takes effect at the next sign-in is not a revoke.

The grant screen: what it must say

Protocols speak in scopes such as files:write, the example the MCP specification uses. Users need sentences. A grant screen that a person can actually agree to answers seven questions in plain language.

1. Who is acting. The agent's name, who built it and who added it to this workspace. Because the agent acts as itself on the user's behalf, not as the user, say so: "Actions will show as the Deal Assistant, acting for you."
2. What it may do. Verbs on objects, in the product's own nouns: "Read your open deals in the EMEA pipeline. Draft follow-up emails."
3. What it may not do. Name the nearest dangerous neighbour of each permission: "It cannot send emails or change deal stages." Users judge a permission by its edge.
4. The limits. The caps from the next section, shown as numbers.
5. For how long. An end date or a scope such as "for this task", never a silent forever.
6. Where to see what it did. A link to the activity view.
7. How to take it back. The exact control, named on the screen where the grant is made.

Translate every scope before it reaches the screen. files:write becomes "create and change files in the folders you choose". If you cannot write the sentence, the scope is too broad to grant.

Ask for little at first. The MCP specification says the scopes a server advertises by default should be the minimal set for basic functionality, with more requested incrementally through step-up. The protocol encodes what we see in practice: a product that asks for everything up front gets either a refusal or a grant nobody understood.

Limits: money, records, time and rate

Scopes say which actions are allowed. Limits say how far each allowed action can go. Show them on the grant screen and enforce them on the server, not in the agent's prompt.

Payments show what a well-formed limit looks like. The Agentic Commerce Protocol's delegated payment allowance binds a payment token to a maximum amount, a currency, one merchant, one checkout session and an expiry time, and supports only one-time use. That is a money limit, a scope and a time limit in a single object, and it is a fair model for any high-stakes action. Rate limits belong on the server too: the MCP tools specification says servers must rate limit tool invocations.

Standing grants, one-off approvals and step-up

Not every permission should last. Decide per action how long an approval holds.

• One-off approval for actions that are irreversible, external or costly: sending, paying, deleting, publishing. OWASP's mitigation is to require a human to approve high-impact actions before they happen.
• Session or task grants for actions that are reversible but frequent, so the user is not asked twenty times during one job.
• Standing grants for low-impact, reversible actions the user has already watched the agent do well.

Claude Code is a useful shipped example of this split. Its permissions documentation shows "Yes, and don't ask again" lasting until the session ends for file edits but saved permanently, per repository, for an approved shell command or web domain. It also offers the standing option only when the prompt can show everything that option would allow; otherwise the user gets a one-time approval. That last rule is worth copying: never save a standing grant the user could not see in full.

Step-up is the moment an agent needs more than it was given. Ask in context, at the point of need, with three answers: allow once, allow for this task or period, and decline. The MCP specification asks servers to name every scope an operation needs in a single challenge rather than one at a time, because asking for one scope after another forces repeated authorisation round trips and, in the specification's words, degrades user experience. Keep the earlier grant intact when the new one is added; the specification has clients request the union of old and new scopes for the same reason.

What the user can see afterwards

A grant the user cannot audit is a grant they will either revoke or forget. Give each agent an activity view that answers, per grant:

• what the agent did, in sentences, with links to the records it touched;
• what it tried and was refused, because refused attempts tell the user whether the grant is too tight or the agent is reaching;
• how much of each limit it has used: money spent against the cap, records changed against the cap;
• which actions can still be undone, with the undo beside them.

The MCP tools specification asks clients to show tool inputs to the user before calling a server and to log tool usage for audit purposes. Microsoft's Entra documentation shows agent activity recorded as the work of an AI agent: sign-ins by Copilot Studio agents, for example, are logged as AI agents. Both point the same way: actions should be attributable to the agent, not blurred into the user's own history. Anthropic's study of agent autonomy in practice (18 February 2026) ends with a recommendation to product developers to invest in tools that give users trustworthy visibility into what agents are doing.

Agents also have to operate screens built for people, and that changes what they can reliably do; our agent-friendly UI experiment looks at what breaks.

The autonomy ladder: suggest, draft, act with approval, act and report

Permissions say what an agent may touch. Autonomy says how much it does before a person looks. Kevin Feng, David McDonald and Amy Zhang of the University of Washington, in a paper on levels of autonomy for AI agents published with the Knight First Amendment Institute, argue that autonomy is a design decision, separate from capability: a capable agent can still be built to consult its user before each action. Their five levels describe the user's role, from operator to observer. For a product team we find four rungs easier to build and to explain, set per action type rather than per agent.

Four rules make the ladder work.

• The user moves it up, prompted by evidence. The product can offer the step: "You approved the last 20 small refunds without changes. Let the agent issue refunds under your set amount and tell you afterwards?" It should never promote silently. You set the counts and thresholds per action type; there is no universal number.
• Rungs are per action type, not per agent. An agent can act and report on tagging tickets while it still only drafts customer replies.
• A changed agent is a new agent. The same paper proposes autonomy certificates tied to the agent's model, prompts and tools. Whatever you call it, a change to any of these is a reason to drop a rung until the record rebuilds.
• Higher rungs need more oversight tools, not fewer. Anthropic found that among new Claude Code users roughly 20% of sessions use full auto-approve, rising to over 40% as users gain experience, and that more experienced users also step in during roughly 9% of turns, where people with around ten sessions step in during 5%. In Anthropic's reading, oversight moves from approving each step to watching and stepping in. The report also warns that requiring a human to approve every action will create friction without necessarily producing safety benefits. So act and report needs a live, readable stream and a stop control within reach.

The new-colleague comparison holds for the shape of this: small, visible permissions first, more as the record shows they are used well, and an obvious way back. It breaks in one place. A colleague's judgement carries over from one week to the next; an agent's can change with a model update, which is why the ladder resets when the agent does. Where the check sits inside a single task is a separate question, covered in our human-in-the-loop UX patterns, and the design of one delegated task in our agentic UX principles.

Lowering autonomy and revoking: a checklist

Taking authority back has to be as easy as giving it, and faster. Three levels of retreat cover most cases: drop a rung for one action type, pause the agent, or revoke the grant.

Revocation has a technical trap. RFC 7009, OAuth 2.0 Token Revocation, requires servers to support revoking refresh tokens but only recommends supporting revocation of access tokens. Where access-token revocation is not supported, tokens already issued keep working until they expire. Short-lived tokens shrink that window; checking the grant at the moment of each action closes it. Claude Code shows the behaviour users expect: a permission rule added or removed mid-task applies from the agent's next tool call.

Before you ship, check that:

• every agent has one place listing its grants, scopes, limits and current rung per action type;
• revoke is one action, reachable from the activity view and from the agent's settings;
• revoke stops work in flight, and the product checks the grant at action time, not only when the token was issued;
• pause exists separately from revoke, so a user can stop the agent without losing the configuration;
• lowering a rung takes effect on the next action, with no confirmation maze;
• grants expire by default, and the user is asked before a standing grant renews;
• after a revoke, the user sees what the agent did under that grant and what can still be undone;
• a model, instruction or tool change to the agent drops affected action types a rung and tells the user why;
• the customer's admin can see and override every user's grants, so the end user's controls sit inside the organisation's.

The plumbing now exists to make an agent's authority explicit, attributable and short-lived. Whether users trust it depends on the screens on top. We design these grant, limit and autonomy flows as part of our work on AI copilots and agents, and on human-in-the-loop workflows where the approval steps carry the weight.