AI agent authorization and permissions

AI agent authorization and permissions are the rules and mechanisms that determine what an identified agent may access or do, such as scoped credentials, delegated authority and least-privilege access. Authorization establishes what an agent is allowed to do, and does not by itself establish whether a permitted action serves the task it was given.

Authorization for agents borrows almost everything from authorization for people and services: credentials, roles, OAuth scopes, policy engines, approval steps. The machinery works. What changes is the relationship between a permission and the work it is used for. A person in a job does broadly similar work for months. An agent may be given a different task every session, by a different person, and decide its own steps at run time. Permissions that fit a role reasonably well fit a single agent task loosely, and the looseness is where most agent authorization problems live.

The mechanisms

The Model Context Protocol’s authorization specification applies OAuth to agents reaching tool servers: tokens are bound to the server they were issued for, and passing a token through to another service is forbidden. OWASP’s guidance on excessive agency adds a principle that applies to all of them: authorization should be enforced in the downstream systems, rather than left to the model to decide whether an action is allowed.

Least privilege is measured against the wrong unit

NIST defines least privilege in two ways that are usually treated as one: the minimum privileges needed to accomplish assigned tasks, and the minimum resources and authorizations an entity needs to perform its function. For a human employee, the task and the function are close. For an agent, they are far apart. Credentials are scoped to what the agent might need across all the tasks it could be given, its function, and then used for one task at a time.

The standards bodies have recognized the granularity problem. RFC 9396, OAuth’s rich authorization requests, exists because a scope string cannot express a single transaction: “transfer 45 euros to merchant A” is not a scope. MCP’s security guidance warns against omnibus scopes because they hide user intent per operation, and recommends requesting additional scopes progressively, as they are needed. But scopes accumulate during a session and rarely shrink. A session’s authority grows while the task stays the same size.

Fine-grained, task-specific authorization already exists. Rich authorization requests can describe a single transaction, policy engines can evaluate each request against its parameters, and some agent platforms evaluate every tool call at a gateway before it reaches the tool. The problem is how authorization is commonly applied to agents. Permissions are often granted broadly, for everything the agent’s role might need, because a narrow grant would have to be issued again for every task, and they are rarely tied to the task the agent is performing right now. Where authorization stops at the level of long-lived credentials, even perfect least privilege will be looser than any single task. The unit that matches the task is a statement of the task itself: what this session is for, and which systems and operations it should need. That is declared scope, and it is a different kind of boundary from a permission.

Allowed is not the same as appropriate

In 1988 Norm Hardy described the confused deputy: a program that misused authority it legitimately held, because another party chose the target. MCP’s security guidance names the problem directly for tool servers. With agents it takes a second form. The target of an action is chosen by model output, and model output can be shaped by content the agent read along the way, as in prompt injection. Every call can be fully authorized and still be confused. Token-level protections, such as binding a token to one server, stop authority from leaking to the wrong place. They do not stop authority from being aimed at the wrong target.

Approval prompts move the decision to a person

The usual answer to “allowed but maybe not appropriate” is to ask a human. That turns authorization into a per-action decision, which is the right granularity. But it puts the decision on someone who sees a stream of them. Anthropic reported in 2026 that users of Claude Code accept 93 percent of permission prompts, and described the result as approval fatigue. A safeguard that is approved almost every time becomes a grant made one click at a time. Per-action checks work best when routine decisions are made automatically against a stated task, and people see only the exceptions.

An example

A support agent holds a credential that can read tickets, update customer records and issue refunds, because across its workload it does all three. Today’s task is to answer a billing question. A message in the ticket thread, written by the customer, says the account email is wrong and asks the agent to change it. The agent updates the email. Every system involved approves the call: the credential permits it, the token is valid for the CRM, and the change is well formed. The action was allowed. Whether it was appropriate, and whether changing an account email at a customer’s request in a ticket is something the business wants an agent to do without verification, are questions no permission in the chain was asked.

Where Sentience fits

Sentience Governor, the free, open-source runtime governance library, supplies the task-level boundary. A session declares its objective and scope, and each attempted action is compared with that scope and the operator’s policy, with the objective kept as context. In the example, a session declared for answering a billing question with a scope of tickets would record the CRM update as an action outside its scope, and flag it. Governor records and flags; it does not refuse calls, and it does not replace authorization. It also has a published limitation: an action inside the declared scope that does not serve the objective is not distinguished today, as the entries on declared scope and agent drift explain.

The Governor Model describes the direction this points: identities, scope and policy adjusted together as an agent works, which the white paper presents as architecture rather than shipped capability. Sentience Runtime Enforcement delivers the run-time decision in your own infrastructure: it evaluates actions at your execution control points against policy, task context and risk, lets routine deviations be course-corrected automatically, escalates consequential ones to your reviewers, and stops execution when required, so people review exceptions rather than every prompt.

Often confused with

Agent identity. Identity establishes who the agent is. Authorization establishes what that identity may do.

Authentication. Authentication proves an identity. Authorization decides what the proven identity is permitted to do.

Least privilege. Least privilege is a principle for setting permissions, not a mechanism. For agents, it is the goal that credential-level authorization struggles to reach for individual tasks.

Declared scope. A permission says what an agent may do in general. A declared scope says what this task should need. The first is granted; the second is stated and checked.

Where the concept stops

Authorization decides whether an identified agent may perform an operation. It does not decide whether that operation serves the task the agent was given, whether the target was chosen by the user or by content the agent read, or whether a person approving the action was paying attention. Those depend on a statement of the task to check each action against, and on run-time decisions that can act on the answer.