Authentication for AI Agents: OAuth Patterns for Non-Human Identity

Key takeaways

• AI agents are non-human principals that act on behalf of a user, an organization, or themselves. The authentication pattern depends on which.
• OAuth 2.0 / 2.1 with on-behalf-of (OBO) tokens is the dominant pattern for user-delegated agent authentication in 2026.
• Dynamic Client Registration (RFC 7591) is how MCP servers and agent platforms register without a human in the loop; pair it with strict registration policies.
• Agent identity is the third leg of the identity stool alongside human and workload identity; conflating any two is the root of most agentic-AI security incidents.
• Token theft from an agent is high-impact: broader scopes, machine speed. Short lifetimes, narrow scopes, and sender-constrained tokens are non-optional.

Why agent authentication is its own problem

The identity stool has three legs in 2026:

• Human identity: a person. Authenticated via passkeys, passwords, MFA. Subject to user-friendly UX.
• Workload identity: a service or process. Authenticated via mTLS, SPIFFE SVIDs, cloud IAM. No UX, all automation.
• Agent identity: an AI agent that runs autonomously but often acts for a user. Combines properties of both — needs the delegation model of human auth, the lifecycle of workload auth, and a couple of patterns unique to itself (model-version provenance, prompt-source attribution, tool-call audit).

Conflating any two of these is the root of most agentic-AI security incidents. An agent running with a human user's full token (treating the agent as the user) means the agent's bugs become the user's compromises. An agent running as a generic service account (treating the agent as a workload) loses the audit trail of which user requested which action. The patterns below keep them separate.

Who is the principal: three scenarios

The authentication pattern depends on which entity the agent is asserting.

1. Agent acting on behalf of a single user, with their consent.

The user has consented (explicitly, through an OAuth authorization screen, or implicitly via terms of service) for the agent to act for them. The agent is calling APIs as the user, scoped to what the user authorized. Example: a calendar agent the user installed in their email client, which schedules meetings on their behalf.

The pattern: OAuth on-behalf-of (OBO) via RFC 8693 token exchange. The agent has its own client_id (registered with the OAuth server). At runtime, the agent takes the user's access token and exchanges it at the token endpoint for a new token, audience set to the downstream API. The new token preserves the user identity in claims; the audit log shows both the user and the agent.

2. Agent acting autonomously as a service.

The agent has its own service principal with its own permissions, not delegated from any user. Example: a monitoring agent that watches the company's logs and pages on-call for anomalies. No specific user is responsible for what it does; the company is.

The pattern: OAuth client_credentials grant. The agent authenticates as itself with client_id and credential (client_secret, mTLS cert, or DPoP key). The resulting access token carries the agent's identity, not a user's. Authorization is configured against the agent's principal.

3. Agent shared across many users.

A shared agent that processes many users' data. Example: a customer-support agent that reads support tickets from all users, no single user is in scope for any one request.

The pattern is context-dependent. If the agent should never see user-specific data, treat it as case 2 (service principal). If the agent processes one user's data per request, the calling code should swap to that user's context — OBO when the upstream call carried a user token, or explicit impersonation guarded by IAM policy when not. The mistake is letting a shared agent accumulate broad user permissions and call APIs ambiguously; the audit log becomes uninterpretable.

Dynamic Client Registration: agent onboarding at scale

OAuth 2.0 traditionally requires a human to register a client through a developer portal: fill out a form, get a client_id. That does not scale to agentic systems where new agents and new MCP servers need to be onboarded at runtime.

RFC 7591 (Dynamic Client Registration, DCR) defines a registration endpoint where clients register themselves programmatically. POST a JSON document describing the client; receive a client_id, client_secret, and a registration_access_token for managing the registration.

The risks DCR introduces:

• Open registration is open registration. Anyone who reaches the endpoint can create a client. Without a gate, the OAuth server becomes a free oracle for client creation and (with poor scope policies) for token issuance.
• Scope inflation. A registered client requests broad scopes; if the server grants what is requested, the new client has whatever permissions the policy permits, regardless of intent.
• Forgotten clients. Programmatic registration without programmatic deprovisioning means thousands of stale client_ids accumulating with valid client_secrets.

The mitigations production deployments use:

1. Initial Access Tokens (IATs): gate the registration endpoint with an IAT — an out-of-band-issued token that authorizes one registration. The IAT issuer is a human; the registration is the agent's.
2. Strict scope policies per registration. The registration metadata declares the scopes the client may request; the OAuth server enforces an allowlist mapped to the IAT class.
3. Software statements (RFC 7591 §2.3): a signed JWT asserting "this software is what it claims to be" — issued by the agent platform vendor, verified by the OAuth server. Combined with attestation, this lets the server know it is registering an instance of a known agent runtime, not arbitrary code.
4. Lifecycle: registrations expire; refresh requires re-attestation; deletion is automated.

The Model Context Protocol (MCP) ecosystem leans heavily on DCR — every MCP server an agent discovers is a new OAuth client. Strict DCR policy is what keeps the discovery model from being an unbounded client-creation oracle.

Sender-constrained tokens: why agents need them more

Bearer tokens are bearer tokens — anyone who has them can use them. For human users that is bad enough; for agents that is worse, because agents:

• Act at machine speed (an hour of stolen-token use is hundreds of API calls).
• Often have broader scopes than humans (the agent for "schedule meetings and respond to email" combines permissions a human would have in two separate sessions).
• Run in environments where token storage is more porous (process memory in a Python script, environment variables in a container, logs from a debugger).

Sender-constrained tokens raise the bar:

• mTLS-bound tokens (RFC 8705): the access token is valid only when presented over a TLS connection where the client presents a specific certificate. Stolen token + no key = useless. The right pick when the agent runs in an environment that supports mTLS — service mesh, server-side runtimes.
• DPoP (RFC 9449): the agent holds a public/private key pair, signs a per-request DPoP proof, includes the key thumbprint in the token. Same property as mTLS, lighter to deploy. Right for agents that cannot do mTLS — browser-running agents, mobile agents, edge functions.

Either is materially stronger than bare bearer tokens for agent use cases. Adopting one before a token-theft incident teaches the lesson is much cheaper than adopting one after.

Token lifetimes for agents

The general rule: agent access tokens should be shorter than the equivalent human access tokens. The reasoning, restated:

• Token theft window is the lifetime. Stolen agent tokens get used immediately; human tokens have a delay while the attacker figures out the UX.
• Agents have broader scope. A token that authorizes 50 distinct API operations is more dangerous than one that authorizes 5.
• Agents do not notice anomalous activity. A human user logs in and sees unfamiliar sessions; the agent runs in a loop and notices nothing.

Reasonable defaults for production agent deployments: access tokens 5–15 minutes, refresh tokens rotated on every use (RFC 6749bis), refresh tokens bound to the client (sender-constrained — mTLS or DPoP).

The detail is covered in Token Management for AI Agents.

Audit and attribution

The audit log for an agent action must record at least:

• User principal (if OBO): who delegated the action.
• Agent principal: which agent took the action.
• Action: which API call, which scope, which resource.
• Source: the prompt or instruction that produced the action, if traceable (some agent runtimes record the LLM input that led to a tool call).
• Model identity: which model version produced the output that became the tool call.

The combination of user + agent + model + action is the new audit primitive for agentic systems. SIEM tools are starting to ingest this; CIAM products that ship strong audit log structure for agent actions (Auth0, Descope, WorkOS, Curity) are the ones building the right primitive.

Implementation guidance

1. Decide whose identity the agent asserts before writing any code. OBO for user-delegated; client_credentials for autonomous; explicit per-request user context for shared agents. Picking later is a refactor.
2. Use OAuth 2.1, not OAuth 2.0. PKCE mandatory, refresh-token rotation mandatory, audience-restricted tokens. OAuth 2.1 Explained for the details.
3. For OBO, implement RFC 8693 token exchange. Most modern OAuth servers (Auth0, Curity, Keycloak, WorkOS, Ory Hydra) support it; pick one that does.
4. Gate DCR with initial-access-tokens and strict scope policies. Open DCR is a security incident waiting.
5. Sender-constrained tokens for agents in production. mTLS where the runtime supports it, DPoP otherwise. Bearer-only is a risk choice you should make consciously.
6. Short access-token lifetimes. 5–15 minutes. Refresh-token rotation. Refresh tokens bound to the client.
7. Audit user + agent + model + action. The combination is what makes incident response possible.
8. Plan for compromise. When an agent's token is stolen, what blast radius does it have? If the answer is "everything the user can do for the next hour," scope reduction and lifetime reduction are urgent.

Go deeper: A comprehensive guide to MCP covers the protocol most agent platforms use to expose tools and data to models.