OAuth for AI Agents Explained: Delegated Access, Tokens, and Key Flows

OAuth for AI agents is a way to give an autonomous agent limited, auditable permission to access APIs and tools—either on behalf of a user or as its own service identity—using scoped and expiring tokens rather than shared passwords or broad static keys.

The right pattern depends on the architecture: Authorization Code with PKCE for user-delegated access, Client Credentials for unattended machine-to-machine agents, and token exchange or on-behalf-of flows when authority moves across downstream services.

What does OAuth mean for AI agents?

In plain language, OAuth is an authorization framework. It lets an AI agent obtain permission to call a tool or API without receiving a user’s password or a permanent, broad API key.

That permission is represented by an access token. The token can be limited by scope, lifetime, audience, and the identity or service allowed to use it. Access can also be monitored, refreshed where appropriate, and revoked.

OAuth primarily answers the question, “What may this client or agent access?” It is different from authentication, which asks who someone or something is. OAuth can carry identity and delegation information, but it does not prove that an agent is trustworthy, reliable, or safe in how it uses an authorized tool.

The main OAuth roles

The parties in an agent authorization flow may include:

• User: the person who may grant access to data or actions.
• AI agent: the automated software that plans or performs a task, such as organizing a calendar or calling a business API.
• Client: the application that requests tokens and makes or coordinates API calls. The client and agent may be separate components.
• Authorization server: the system that authenticates the relevant party, obtains consent when required, and issues tokens.
• Resource server: the API or tool that receives a token, validates it, and enforces its permissions.

Keeping the user, client, and agent identities distinct can improve policy decisions and auditability. It does not, by itself, grant permission or make an action safe.

User-delegated agents versus service agents

The central design question is whether the agent acts for a user or as an independent service.

When an agent acts for a user

A user-delegated agent uses authority granted by a person. This model fits a calendar assistant, email agent, or support agent working with a user’s account. The user’s permissions, consent, and organizational policies help define what the agent can access.

For example, a calendar agent might be allowed to read events and create appointments but not delete an entire calendar. The boundary comes from scopes and policy—not from giving the agent the user’s password.

When an agent operates independently

An unattended background agent may run on a schedule or respond to events without a user being present. It can use Client Credentials, or an equivalent machine-to-machine pattern, to obtain a token for its own service-level authority.

A background service might call an inventory API, reconcile records, and submit an operational report. It does not need a human consent screen for every run. Instead, an administrator or system owner establishes the service’s permissions and monitors its activity.

This is still different from giving the agent a shared, permanent service-account password. A distinct service identity, scoped and expiring tokens, revocation, logging, and activity limits provide stronger control.

Which OAuth flow should an AI agent use?

Use Authorization Code with PKCE when a user must consent and the agent acts within that user’s permissions. Use Client Credentials when an unattended agent has its own service authority. Use token exchange or an on-behalf-of flow when a downstream API or tool needs a suitably limited token instead of the original token.

No single flow fits every AI-agent architecture. The correct choice depends on the relationship between the user, client, agent, authorization server, resource server, and downstream services.

How Authorization Code with PKCE works

For a user-delegated calendar or email agent, the flow commonly looks like this:

1. The user asks the agent to perform a task.
2. The application directs the user to the authorization server and requests specific permissions, such as reading calendar events or creating a draft.
3. The user authenticates and provides consent according to the authorization server’s policies.
4. The authorization server returns a short-lived authorization code.
5. The application exchanges the code, together with the PKCE proof, for an access token.
6. The agent sends the access token when calling the calendar or email API.
7. The resource server validates the token and enforces its scopes and other restrictions.

PKCE helps bind the code exchange to the application that began the flow. The application should also validate the flow’s state. Authorization codes should be short-lived, single-use, and bound to the intended client and delegated context where applicable.

Access tokens should expire. If continued access is appropriate, the application can use a refresh token according to the provider’s rules. Refresh tokens require careful protection and rotation where supported. A user or administrator should also be able to revoke access or require consent again.

Scopes, delegation, and least privilege

Scopes describe what a token permits. For an AI agent, scopes should match a specific task rather than grant broad administrative access.

Useful boundaries include:

• Read rather than write access.
• Access to one API or resource type rather than an entire account.
• Permission to create a draft rather than send a message.
• Permission to view appointments rather than delete them.

Least privilege limits the consequences of a compromised token, configuration error, or agent that misuses an available tool. It also makes authorization decisions easier to review.

Delegation versus impersonation

In one transaction, several identities may matter:

• User: who authorized access when user delegation applies.
• Client: which application initiated the token request.
• Agent: which automated actor performed the task.

With delegation, these identities can remain distinct. A resource server may then determine who authorized an action, which application initiated it, and which agent acted. With impersonation, the agent appears as the user within the token’s authority, which can reduce visibility of the separate automated actor.

Token validation and lifecycle safeguards

OAuth security depends on what happens after a token is issued. Before honoring an API request, the resource server should validate the token according to its design, including relevant checks for:

• Issuer: whether the trusted authorization server issued the token.
• Audience: whether the token is intended for this API or tool.
• Signature and keys: whether a signed token is valid under the issuer’s published keys.
• Expiration: whether the token is still within its permitted lifetime.
• Scopes and delegation claims: whether the token authorizes this operation and accurately represents the relevant context.

JWTs can be validated locally using the issuer’s published keys. Opaque tokens can require introspection instead. The resource server—not only the agent—must enforce the authorization decision.

A practical AI-agent authorization design should also include:

• Short-lived access tokens to reduce the period in which a leaked token can be used.
• Refresh-token protection and rotation where applicable.
• Secure storage that keeps tokens out of source code, user-visible data, and ordinary logs.
• Revocation and renewed consent so access can be withdrawn or authorization requested again.
• Audit logs for relevant consent, identity, token, and action events without recording secret token values.
• Monitoring and rate controls for unusual access, repeated failures, excessive requests, tool use, and operational cost.
• Sender-constrained tokens, such as DPoP or mTLS, when the threat model and platform support justify them.

Tenant isolation in production

In a multi-tenant system, authorization data must remain associated with the correct tenant. Isolation should cover token storage, encryption keys, refresh jobs, caches, outbound calls, and audit logs—not just the application’s primary database.

Tenant context should be carried consistently through token handling and policy checks. A valid token for one tenant must not become a way to retrieve another tenant’s credentials, cached authority, or audit history.

OAuth with MCP and agent-to-agent systems

MCP is an integration context in which an AI application or agent connects to remote tools and services. It is not the definition of OAuth for agents. Different MCP deployments and providers can have different registration, discovery, authorization, and token-handling behavior.

A typical sequence is:

1. The host application or agent runtime identifies the remote MCP endpoint and requests the authority needed for a tool call.
2. The authorization server authenticates the relevant party and obtains user consent when the agent acts on the user’s behalf.
3. The authorization server issues a token for the intended audience and scopes.
4. The agent runtime calls the MCP endpoint with that token.
5. The MCP endpoint validates the token and enforces its own resource policy.
6. If the endpoint calls another API, token exchange or an on-behalf-of pattern can provide downstream authority with appropriate audience, scope, and user context.

Similarly, one agent or service may call another agent-facing API. Standard OAuth patterns can authorize those calls, while token exchange can give the downstream service narrower or otherwise appropriate authority.

Token exchange and on-behalf-of authorization

Downstream calls create a chain of authority: a user or service authorizes one component, and that component needs to call another API or tool. Passing the original token everywhere can give the downstream service more authority than it needs.

Token exchange or an on-behalf-of flow can issue a token for the downstream audience with suitable scopes while preserving relevant user, client, or agent context. The exact behavior depends on the identity provider and architecture.

An agent-specific on-behalf-of proposal has also been described in an IETF Internet-Draft. It discusses concepts intended to keep the acting agent visible rather than collapsing every action into the user’s identity. Because it is a developing draft, it should not be treated as a universal requirement or finished standard.

What OAuth does not solve

OAuth does not automatically make an AI agent trustworthy or safe. It controls whether a client or agent has authority to call a particular API or tool. It does not determine whether the next action is sensible, aligned with the user’s intent, or harmless.

Additional controls may be needed for:

• Manipulation risks and unsafe instructions.
• Tool misuse, including actions that are technically authorized but harmful.
• Human approval for sensitive or irreversible actions.
• Policy enforcement, monitoring, and investigation.
• Secure handling of tokens across the agent runtime, tools, and downstream services.

What are the five parts of an AI agent?

OAuth does not define a universal five-part model for AI agents. For authorization, focus on the agent, the client, the authorization server, and the resource server involved in the access decision.

Practical decision checklist

1. Identify whether the agent acts for a user or operates as an independent service.
2. Choose Authorization Code with PKCE for user delegation, Client Credentials for unattended service authority, or token exchange/on-behalf-of for downstream authority.
3. Define narrow, task-specific scopes and separate read from write access where appropriate.
4. Keep user, client, and agent identities distinct when auditability and policy enforcement require it.
5. Use short-lived tokens and protect refresh tokens and other credentials in secure storage.
6. Validate issuer, audience, signature, expiration, scopes, and relevant delegation claims before granting API access.
7. Maintain tenant isolation across token storage, keys, refresh processes, caches, outbound calls, and logs.
8. Keep secrets out of logs, provide revocation or renewed consent, and monitor agent activity, failures, rates, and costs.

OAuth for AI agents is authorization, not a complete agent-safety system. Its value is giving an agent limited, expiring, and auditable access instead of a password or broad static key. The safest pattern is the one that matches the agent’s authority model and keeps that authority narrow, observable, and properly enforced.