AI Agent Authorization: Tool Access, Delegation, and Least Privilege

AI agent authorization decides which tools, resources, data, and actions an agent may use under a principal’s authority. The decision accounts for the agent identity, represented user or service, target, operation, conditions, and current task. Authentication alone does not answer those questions.

Existing OAuth and workload identity standards supply many components, while agent-specific delegation remains active standards work. NIST’s 2026 software and AI agent identity concept paper still asks how agents should prove authority, preserve delegation, apply least privilege, and support audit. Implementations should distinguish published standards from local profiles and drafts.

Key Takeaways

• Authenticate the user, agent workload, and target service separately, then evaluate authorization for each protected action.
• Give delegated and autonomous agents resource-bound, short-lived permissions that cannot grow during task handoffs.
• Treat MCP transport authorization as one layer and enforce tool, argument, data, and business policy at the server.
• Record the principal, agent, grant, policy decision, approval, tool call, result, and revocation state for each sensitive action.

Authentication and Authorization Answer Different Agent Questions

Authentication establishes an identity claim under an issuer or trust domain. Authorization decides whether that identity may perform a particular action on a resource. An authenticated agent can still be unauthorized to read a file, send a message, change a cloud rule, or invoke another agent.

NIST SP 800-63-4 covers identity proofing, authentication, and federation for people. It does not cover machine-to-machine authentication. Agent deployments need a workload or client identity mechanism beside the user flow.

Preserve both the user and agent identities

If an agent acts for a user, logs and tokens should not collapse them into one subject. The user is the delegating principal, while the runtime is the actor. Keeping both supports policy, investigation, and revocation.

An autonomous agent may have no active user. It can authenticate as a service or workload and receive authority from organizational policy. That authority should be bounded to its scheduled job, environment, and approved resources.

User-Delegated and Autonomous Access Need Different Grants

User-delegated access begins with a user authorization. The grant should identify the agent, resource, operations, lifetime, and conditions. High-impact work may need approval at execution time if the exact target was unknown during the initial grant.

Autonomous access uses a service authority rather than a live user session. It should not inherit an administrator’s general token simply because an administrator configured the job.

Delegation should preserve who authorized whom

OAuth 2.0 Token Exchange, RFC 8693, defines token exchange and can express subject and actor relationships for delegation or impersonation. It is not a complete AI agent delegation profile. Deployments need policy for which actors may exchange tokens and how authority narrows across hops.

Agent-specific proposals exist in the IETF, but Internet-Drafts can change or expire. Do not describe a draft delegation claim or token format as an established standard. If a system adopts one, document its version, trust model, and interoperability limits.

OAuth Tokens Must Limit Resource, Scope, and Lifetime

An access token represents authorization issued for a client at a protected resource. The agent should receive a token intended for that service, with narrow permission and a task-appropriate lifetime. A bearer token copied into a prompt, trace, or tool response can be replayed.

RFC 8707 defines the OAuth resource parameter so a client can identify where it intends to use a token. Audience restriction limits reuse at another service. The RFC warns that multi-audience tokens require high trust between recipients.

Scopes alone may be too broad for tool operations

A scope such as calendar.write may cover several actions and every calendar the user can access. OAuth 2.0 Rich Authorization Requests, RFC 9396, defines structured authorization details that an API profile can use for actions, locations, data types, or other fields. The API still has to define those fields and enforce their meaning.

Fine-grained policy can use resource attributes, ownership, data classification, transaction amount, task state, or time. The enforcement point needs trusted access to those inputs. Model-generated arguments are request data, not trusted claims.

MCP Authorization Protects the Server, Not Every Tool Decision

The current MCP authorization specification uses OAuth for HTTP transports. A protected MCP server is a resource server, and the client requests tokens for its canonical resource identifier. The specification supports incremental scope requests.

This transport authorization controls access to the MCP server. It does not define the business authorization model for every tool, argument, tenant, or data object exposed by the server. That conclusion is an architectural inference from the specification’s scope, not a separate MCP standard.

Tool discovery is not permission to execute

An agent may learn that a tool exists through a tool listing. The server should still evaluate permission at invocation because context, ownership, arguments, or risk may have changed. Descriptions and schemas do not grant authority.

Servers can map scopes or authorization details to tools, then apply finer policy inside the operation. A files.write scope might permit the tool while object policy limits it to one project directory. Destructive actions may require a separate scope and fresh approval.

Least Privilege Needs Capability and Data Boundaries

Least privilege for an agent means limiting available tools, actions, resources, data, credentials, and delegation depth to the task. Hiding a tool from the model can reduce accidental selection, but enforcement must occur outside the model. A compromised or injected agent should meet the same denial at the resource boundary.

Capability boundaries should distinguish read, create, update, delete, execute, approve, and delegate where the service supports them. They should also limit objects or tenants, not just verbs. An agent allowed to update one ticket should not receive authority to edit every ticket visible to the user.

Memory and retrieval need explicit access rules

Agent memory can contain material retrieved under a user’s authority. A later run should not inherit that material merely because it uses the same agent definition. Memory stores need subject binding, retention rules, authorization checks, and deletion paths.

Retrieval should preserve source identity and policy context. The final response may combine records with different disclosure limits, so output policy may need to evaluate the destination and audience. The NIST concept paper specifically raises the risk created when agents aggregate data from several tools.

Approvals Should Bind to Machine-Readable Actions

Human approval is useful when an operation is destructive, financially material, externally visible, or privilege-changing. The approval should identify the agent, represented principal, target resource, operation, important parameters, expiration, and whether one or several executions are allowed. “Approve this plan” is weak if the plan can change before execution.

The NIST AI RMF Core calls for defined human oversight, documented system scope, and production monitoring. It does not prescribe an agent approval protocol. Teams must convert oversight policy into an enforceable decision at the relevant tool boundary.

Step-up approval should not expand the base grant

An approval can permit one operation that the base policy marks as eligible for escalation. It should not turn a narrow token into a reusable administrator credential. The resulting authority should be short-lived and tied to the approved resource and parameters.

If an agent changes the amount, recipient, repository, or destination after approval, it needs a new decision. The authorization record should make parameter substitution detectable.

Confused Deputy Controls Must Stop Token Forwarding

A confused deputy uses its own authority to satisfy a request that the requester was not entitled to make. Agent systems face this risk when an orchestrator, MCP server, or tool service accepts a request under one context and calls another service with a broader credential. Prompt injection can supply the untrusted request, but excessive downstream authority creates the impact.

The MCP specification explicitly forbids token passthrough. An MCP server must accept a token intended for itself and obtain a separate token for an upstream API rather than forwarding the client’s token. Resource and audience binding let each service reject tokens created for another destination.

Token exchange needs an authorization policy

Token exchange can create a narrower token for a downstream service, but the exchange endpoint must authenticate the client and evaluate whether it may receive delegated authority. RFC 8693 warns that omitting client authentication can let anyone holding a compromised token exchange it. The service should also preserve actor information needed for audit.

Do not allow each agent hop to copy the full parent permission set. Subtasks should receive an explicit subset and a shorter lifetime where practical. Delegation depth and onward delegation should be policy decisions rather than silent defaults.

Revocation Must Stop Long-Running Agent Work

Short-lived tokens limit future use after theft or task completion. OAuth 2.0 Token Revocation, RFC 7009, lets a client ask an authorization server to invalidate an access or refresh token. Resource servers also need a validation method that reflects revocation within the required response time.

An agent may continue through queues, scheduled tasks, cached decisions, or delegated subtasks after the interactive session ends. Revocation therefore needs to reach the orchestration layer as well as the token service. Cancel pending operations, terminate child tasks, and clear stored authority associated with the grant.

Emergency revocation needs a tested path

Teams should be able to disable one agent instance, one configured agent, one user delegation, or an entire issuer relationship. Tests should confirm how quickly each enforcement point rejects old authority and what happens to in-flight work.

Credential rotation is related but different. Rotating a workload credential replaces proof of identity, while revoking a grant removes permission. An incident may require both actions.

Audit Records Should Reconstruct the Authorization Decision

Record the initiating principal, agent instance, client or workload identity, token identifier, issuer, audience, scope or authorization details, policy version, tool, parameters, approval, result, and timestamp. Link downstream calls with a correlation identifier. Protect secrets and sensitive arguments through redaction, hashing, or restricted storage.

A model transcript alone is insufficient. It may show a proposed reason without recording the credential, policy evaluation, retries, or API response that determined what occurred. Security audit should come from the control and execution layers.

The OWASP Top 10 for Agentic Applications identifies tool misuse and identity and privilege abuse as risks. Authorization limits impact, while audit shows whether policy worked. The prompt injection and workload identity entries cover adjacent concepts.

Frequently Asked Questions

What is the difference between agent authentication and authorization?

Authentication verifies an identity under an issuer or trust domain. Authorization decides whether that identity may perform a requested operation on a resource. An authenticated agent still needs a policy decision for each protected action.

Can an AI agent use a user’s OAuth token?

An agent can act under user-delegated OAuth authority when the flow and service support it. The token should be intended for the target resource, limited in permission and lifetime, and bound to the approved grant. Systems should preserve the agent as the actor instead of recording every call as a direct user action.

Does MCP provide tool-level authorization?

MCP defines an OAuth-based authorization layer for protected HTTP servers. Server scopes can help control access, but the specification does not define every tool’s business policy or object permissions. The MCP server must enforce those rules when the tool is called.

How should an organization revoke agent access?

Revoke relevant access and refresh tokens, stop the agent task, and cancel delegated or queued work. Clear cached policy decisions and stored authority linked to the grant. Test when each resource begins rejecting the revoked access.

AI Agent Authorization Must Survive an Unsafe Plan

AI agent authorization should assume that a model can select the wrong tool, accept a hostile instruction, or construct unsafe arguments. The identity and policy layers must still limit the resource, action, data, and delegation available. Approval, revocation, and audit complete that boundary.

Published OAuth RFCs and the MCP specification do not create one universal agent authorization design. A deployment needs a principal model, trust boundaries, token profile, tool policy, and failure behavior. A resource must be able to enforce why this agent may perform this action now.