Agent Authorization: How to Decide What AI Agents May Do

Every request an AI agent makes raises two questions. Who is calling, and is this call allowed? The first has a settled answer: give the agent an identity and authenticate it. The second is where agent deployments actually break, because an agent chooses its own next action, and no permission you grant in advance knows what it will pick.

Agent authorization is the discipline of answering that second question correctly, one action at a time. Get it right and a compromised agent is a contained incident. Get it wrong and the agent does exactly what it was permitted to do, at machine speed, with a log entry that names a service account instead of a person.

This guide covers what agent authorization is, why role-based grants fail for agents specifically, which authorization model to choose, how delegated authority travels in a token, what the standards bodies are building, and where the decision has to be made so that a prompt cannot move it.

What is agent authorization?

Agent authorization is the process of deciding whether a specific agent may take a specific action on a specific resource, under current policy and the authority delegated to it by a human. The decision is made per action rather than granted once, and it is made before the action executes rather than reviewed afterwards. When policy routes that decision to a person instead of resolving it automatically, you are running human in the loop approval.

The definition applies equally to classic software agents and to model-driven ones. Software and AI agent identity and authorization are the same problem with different failure modes: a scripted integration does a fixed set of things badly when compromised, and a model-driven agent does an open-ended set of things plausibly. Both need their own identity and their own grant. Only one of them can be talked into changing its mind.

Three properties separate real agent authorization from a permissions checkbox:

• Per action, not per session. One verdict per call, evaluated against what the agent is trying to do right now. A session-wide grant is a blank cheque with a timer on it.
• Delegation-aware. The decision knows which human's authority the agent is spending, and it caps the agent at that human's entitlements.
• Enforced outside the model. The component that says yes or no is not something the model can write to, argue with, or be tricked into rewriting.

Authentication and authorization are different questions

AI agent authentication and authorization get discussed as one topic and solved as one project, which is how the harder half gets underfunded. They are not the same question.

	Authentication	Authorization
Question	Who is calling?	Is this specific call allowed?
Answered	Once per session or per credential	Every action
Input	A credential the caller presents	Identity, delegation, action, resource, context
Failure mode	An impostor gets in	A legitimate caller does something it should not
Hard part for agents	Mostly solved by giving each agent an identity	The agent decides its own next action

Authentication for agents is largely a matter of not skipping it. Authorization is the open problem, and it is the one this page is about.

Why role-based grants break for AI agents

Role-based access control works because human jobs are stable. A support representative does support things, so you grant the support role and move on. The grant is a reasonable prediction of what the person will need, and when the prediction is wrong, the person files a ticket.

An agent does not file a ticket. It reasons about its goal, looks at the tools it can reach, and picks. So the role you grant has to cover not the actions the agent will take, but every action it might plausibly decide to take while pursuing its objective. That is a much larger set, and it grows every time someone adds a tool.

OWASP has a name for the result. Excessive agency is the risk of granting an agent more permission, more functionality, or more autonomy than its task requires, and the damage is done by the extra capability being used rather than by the agent being breached. A role broad enough to keep an agent from getting stuck is, by construction, excessive agency written into your identity provider.

Two structural facts make this worse than it sounds. Agents are non-human identities, and they proliferate faster than anyone governs them, so the over-broad role gets copied to the next agent as a template. And agents act unattended, so the gap between a wrong decision and a human noticing is measured in log-review cycles.

The fix is not a tighter role. It is moving the decision from provisioning time to request time.

Choosing an authorization model

Four models are actually in use. They differ on two axes: how finely a grant can be expressed, and how much of the current situation the decision can see.

Model	How a grant is expressed	Strength for agents	Fails first when
RBAC (role-based)	Subject is assigned a role; the role holds permissions	Simple, universally supported, easy to audit	The agent needs an action outside its role, so the role gets widened until it covers everything
ABAC (attribute-based)	Rules over subject, object, action, and environment attributes	The decision can see context: time, sensitivity, risk, source	Action granularity stays coarse and rule sets become hard to reason about at scale
ReBAC (relationship-based)	Permission derives from a graph of relationships between subjects and objects	Excellent for per-object questions such as "may this agent read this document"	The question is not about an object relationship but about an action's risk right now
Policy-based (per-action, runtime)	A policy engine returns a verdict for a concrete request, using identity, delegation, action, resource, and context	Matches how agents behave: one verdict per action, delegation-aware, context-aware	Latency and policy sprawl, both of which are engineering problems rather than model limits

Attribute-based access control is the formal ancestor of the runtime approach, and NIST's guide to attribute-based access control is still the clearest statement of the idea that a decision should be computed from subject, object, action, and environment attributes rather than looked up from a table.

In practice most teams end up with a hybrid: coarse roles to establish a floor, relationships for object-level questions, and a policy decision at request time for anything an agent initiates. That is fine. What is not fine is leaving the agent path on roles alone.

Authenticated delegation: the agent borrows authority

An agent almost never has authority of its own. It has authority someone lent it. That is the single most important thing to model correctly, and it is why AI agents need authenticated delegation rather than a service account with a permissions list.

Authenticated delegation means the agent's request carries cryptographic evidence of three things: which agent is calling, which human delegated the task, and what that human consented to. Delegated authority for AI agents is bounded by the delegating human's own entitlements, so an agent can never do something its principal could not do directly. Without that binding you have an agent with standing power and no one to attribute it to.

The on-behalf-of flow

The OAuth on-behalf-of flow is how this is implemented. A user authorizes an agent for a defined scope, the agent receives a token that records both itself and the user, and when the agent calls a downstream service the token is exchanged for a narrower one that preserves both identities.

1. The user consents to a named agent taking a defined set of actions. Consent is to this agent and these scopes, not to agents generally.
2. A token is issued that records the agent as the acting party and the user as the party whose authority is being exercised.
3. The agent calls a tool and presents that token rather than a credential of its own.
4. The token is exchanged for one scoped to the next service, preserving both identities down the chain instead of forwarding the original.
5. The resource decides and logs, recording the verdict alongside both the agent and the human.

Actor and subject: what the token has to carry

The mechanism underneath step four is OAuth 2.0 Token Exchange, which distinguishes the party acting from the party on whose behalf the action is taken: an actor token and a subject token go in, and the issued token keeps the two apart. That distinction is the whole ballgame. Collapse the agent and the user into one identity and you have impersonation, which authorizes correctly and audits uselessly.

Forwarding matters as much as issuing. A token passed unchanged from hop to hop turns one over-permissive grant into a chain of them. Exchange at every boundary, and keep the chain visible in the claims.

What the standards bodies are building

IETF AI agent authentication and authorization is an active area of work rather than a settled one, which is useful to know before you commit an architecture to a single vendor's shape.

• A draft specifically on AI agent authentication and authorization sets out how agents should be identified and authorized as distinct principals rather than squeezed into user or service-account models.
• An on-behalf-of extension to OAuth for AI agents carries the agent's identity through the consent screen and into the access token, so a user can grant a specific agent specific powers and every downstream system can see who acted.
• The OAuth working group's identity assertion authorization grant handles the cross-domain case, where an agent needs resources behind a different authorization server, while preserving the distinction between the actor and the resource owner.

These are drafts. They will change, and some will not ship. Design to the shape they share, which is an identity per agent plus a delegation chain in the token, and you will be able to adopt whichever wins without re-architecting.

On the tool side, the MCP identity model matters because the Model Context Protocol is where most agent tool calls now terminate, and its specification defines how a client is authorized to invoke a server's tools.

Where the authorization decision belongs

Two separations decide whether any of the above survives production.

The first is architectural and long-established. The component that decides should be separate from the component that enforces. NIST's zero trust architecture names these the policy decision point and the policy enforcement point, and requires the decision to be made per request rather than inherited from a prior grant. Separation is what lets you change a rule in one place and have every enforcement point honour it immediately.

• Callers on the left: the agent itself, the orchestrator coordinating several agents, and the scheduled jobs that run without anyone present.
• The policy decision point in the middle: one verdict per action, computed from the agent identity, the delegating human, the requested action, the target resource, and current context.
• Enforcement points on the right: the MCP server, the SaaS API, the database. Each enforces the verdict; none of them owns the policy.

The second separation is newer and matters more. The decision must be made outside the model, before the action executes. An agent's instructions are data, and data can be attacker-controlled. Prompt injection, poisoned tool descriptions, and malicious content retrieved mid-task are all ways of persuading an agent to want something it should not, and the catalogue of agentic threats is full of variations on tool misuse and privilege compromise. The specific mechanics are covered in our guide to AI agent attacks.

None of that matters if the verdict is produced by something the model cannot influence. An agent that has been talked into attempting a transfer still gets a denial, because the policy engine never read the prompt. Authorization inside the agent, by contrast, is a suggestion.

In practice the enforcement point for tool calls is a gateway, which is the argument for MCP access control, and where that gateway sits relative to the model and the tools is a structural choice covered in AI agent architecture.

After the decision: what the agent actually holds

A verdict is not a credential. Once the decision is yes, the agent still needs something to present to the resource, and the safest version of that is narrow and short-lived: an ephemeral credential minted for the approved action and expiring on its own. Authorization decides; the credential carries the decision.

And when a requested action falls outside what the delegation should cover automatically, the right answer is not to widen the grant. It is to ask the person. Step-up authentication interrupts the agent and requires the human to approve that specific action before it proceeds, which keeps a human-in-the-loop exactly where the risk is instead of everywhere.

Ownership and accountability

Who is accountable for AI agents is the question every security leader asks first and most architectures answer last. It is not a philosophical question. It is a data-model question, and it has a concrete answer: the audit record has to carry enough identity to name a person.

AI agent ownership and AI agent accountability are separate layers, and conflating them is why incident reviews stall:

• Named human owner. A specific person, not a team alias, who answers for what this agent is permitted to do at all. Owner-less agents are how estates rot, because nobody has standing to revoke them.
• Delegating principal. The person whose authority this particular action spends. Often different from the owner, and it is the one the incident review needs.
• Agent identity. First-class, one per agent, never shared, never a human's account. Frontegg makes the same point about treating agent identity as first-class: an agent using a person's credentials is invisible in every log that matters.
• Action record. Verdict, scope, both identities, timestamp. If any field is missing, the question "who is accountable for this agent" has no answer that survives an auditor.

This is the runtime half of a wider program. The policy, review, and approval structure around it belongs to AI agent governance.

Managing agent permissions over time

AI agent permissions management is where the model meets operations, and it fails in the same ways identity management has always failed, only faster.

1. Provision with an owner or not at all. No agent gets an identity without a named human attached. Enforce it at creation, because backfilling ownership across a live estate is a quarter of work nobody funds.
2. Grant the task, not the role. Start from the actions the agent must take and derive the grant. Copying an existing agent's permissions is how over-provisioning spreads.
3. Review on a cadence and on change. Any new tool connected to an agent is a permission change and should trigger a review, not just a deployment.
4. Watch for grant drift. Permissions widen after incidents and never narrow again. Track the direction of change per agent and treat sustained widening as a finding.
5. Alert on unused authority. An agent that has never used a permission in ninety days does not need it. Unused grants are pure blast radius.
6. Decommission properly. When an agent is retired, revoke its identity, its grants, and its tool connections. A dormant agent with live permissions is an unattended account by another name.

Ranking this work is easier with a view of what each agent can actually reach. An agentic risk map gives you that ordering.

What agent authorization cannot do

Four honest limits, because a control oversold is a control that gets blamed.

• It cannot stop a correctly-authorized bad decision. If an agent is allowed to send the email and the email is wrong, authorization approved it. That failure belongs to task design and human-in-the-loop placement, not to the policy engine.
• It cannot repair an over-broad grant. A perfect decision against a permissive policy returns yes. The quality of the answer is capped by the quality of the grant.
• It cannot see intent. A policy engine sees an action, a resource, and context. It does not know whether the agent was reasoning soundly or had been manipulated three steps earlier. That is why detection and audit stay necessary.
• It is not free. A verdict per action is a call per action. It has to be fast enough to sit in the request path, and the budget for it needs to be set deliberately rather than discovered in an incident.

An implementation checklist

1. Give every agent its own identity, with a named human owner recorded at creation.
2. Separate the decision from the enforcement, and let the enforcement points be many while the policy stays one.
3. Make the decision per action, at request time, against the current context.
4. Carry the delegation chain in the token: the agent as actor, the human as subject.
5. Cap every agent at its delegating human's entitlements, with no exceptions for convenience.
6. Exchange tokens at every hop rather than forwarding them unchanged.
7. Keep the decision outside the model, so no prompt can reach it.
8. Route anything above the delegation threshold to a step-up approval instead of widening the grant.
9. Log verdict, scope, both identities, and timestamp on every decision, including the denials.
10. Review grants on a cadence and on every tool change, and decommission retired agents completely.

Related controls in this cluster

• Ephemeral credentials cover what the agent holds once a decision goes its way: short-lived, scoped credentials minted per action instead of standing keys.
• Step-up authentication covers when to stop and ask the human, and how to trigger that check on the right actions rather than all of them.
• MCP access control covers enforcement at the gateway where agent tool calls are actually intercepted.
• AI agent governance covers the program around all of this: policy, approval, ownership, and audit across the whole agent estate.

Frequently asked questions

What is agent authorization?

Agent authorization is the process of deciding whether a specific agent may take a specific action on a specific resource, under current policy and the authority a human delegated to it. The decision is made per action rather than granted once, and it is made before the action executes rather than audited afterwards.

What is the difference between agent authentication and agent authorization?

Authentication answers who is calling and is settled once per credential. Authorization answers whether this particular call is allowed and has to be answered every time. For AI agents authentication is largely solved by issuing each agent an identity. Authorization is the hard half, because the agent chooses its own next action.

How do you authorize an AI agent?

Give the agent its own identity, record which human delegated the task, and evaluate every action against policy at request time using a decision point the model cannot influence. Cap the agent at its delegating human's entitlements, then issue a narrow short-lived credential for the approved action.

What is the OAuth on-behalf-of flow?

It is the pattern where a service acts for a user rather than for itself. The user consents to a specific agent and scope, a token is issued naming both the agent and the user, and each downstream hop exchanges that token for a narrower one that preserves both identities so the final resource can attribute the action.

Who is accountable when an AI agent does something wrong?

The named human owner of the agent is accountable for what it was permitted to do, and the delegating principal is accountable for the specific action taken on their authority. That only works if the audit record carries the verdict, the scope, the agent identity, and the human identity together.

Can an AI agent have more permissions than the user it acts for?

It should not. Delegated authority is bounded by the delegating human's own entitlements, so an agent acting for someone must never be able to do what that person could not do directly. An agent that exceeds its principal is either running on a standing service account or has been granted authority nobody reviewed.

Decide per action, not per role

Authentication tells you which agent is calling. Agent authorization tells you whether this call is allowed, and for anything autonomous that is the decision that matters. Make it per action, at runtime, against the authority a named human delegated, in a component the model cannot reach. Then log it in a way that can name that person afterwards.

Agen gives every agent its own identity and authorizes each action at runtime, with the human behind the agent carried through to the audit record. See how that works in the identity foundation for every AI agent.