# Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 2

> Part 2 of 4. Start with [Authentication Trends in 2026: Passkeys, AI Agents, and Edge](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge.md).

# Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 2

_This is the second part of a four-part series on 2026 authentication trends. While Part 1 covered the mainstream adoption of passkeys for human users, this installment focuses on the second structural shift: treating AI agents as first-class authentication principals with their own identity, scopes, and delegation chains._

## Trend 2: AI Agents as First-Class Authentication Principals

The second major shift in 2026 authentication is that identity providers, standards bodies, and protocol designers now treat AI agents as a distinct principal type — not a special case of either human users or machine clients. This section covers what changed, the standards underneath the change, and the concrete patterns teams are using when agents call APIs on behalf of users or organizations.

### Why AI agent authentication needs its own model

For this article, an **AI agent** is non-human software that uses LLM reasoning to call APIs or tools on behalf of a user or organization. Examples include a productivity assistant that reads a user's calendar, a backend summarization service that invokes an internal search API, and an IDE coding agent that edits files and opens pull requests.

Reusing a human user's session for an agent is the wrong primitive on four counts:

- **Attribution.** [Audit logs](https://clerk.com/glossary/audit-logs.md) need to answer "was this action taken by the human or by the agent acting for the human?" A raw user session collapses both into one identity.
- **Revocation.** If a user wants to disable one agent without logging out everywhere, a shared session gives the security team no handle to pull.
- **Scope.** A human's browser session typically carries broad permissions. An agent invoking a specific tool should carry only the permissions required for that call.
- **Audit.** Compliance and incident review need the full chain: which agent, which user, which tool, which resource, which time window.

A modern auth system therefore has to distinguish three principals as table stakes: **human users**, **machine clients** (internal and third-party services), and **agents-on-behalf-of-users**. The third category is where the 2025-Q4 through 2026-Q1 product wave landed.

Every major identity vendor now ships agent-specific identity primitives. Okta announced [Okta for AI Agents](https://www.okta.com/blog/ai/okta-ai-agents-early-access-announcement/) with an Agent Gateway and a virtual MCP server as part of its "Secure Agentic Enterprise" blueprint. Auth0 shipped [Auth0 for AI Agents](https://auth0.com/ai) plus its Token Vault for agent secrets. Microsoft launched [Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/what-is-agent-id-platform) in preview as part of Microsoft Agent 365. Google Cloud is previewing Agent Identities. Descope released [Agentic Identity Hub 2.0](https://www.descope.com/press-release/agentic-identity-hub-2.0). Scalekit offers [MCP Auth and Agent Actions](https://docs.scalekit.com/). And Clerk's [October 2025 Series C](https://clerk.com/blog/series-c.md) explicitly earmarked capital for agent identity work.

The honest callout: despite the productization, enterprise _governance_ of agent identity is immature. Strata's February 2026 research found only **18% of enterprises** report confidence in their agent-identity governance. The OpenID Foundation's October 2025 paper, [Identity Management for Agentic AI](https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf), argues that existing standards _can_ secure agentic use cases today but recommends specialized authorization servers and clean separation of concerns from human-user flows. Most production agent auth in the wild is still ad-hoc personal access tokens and API keys; the standards-aligned stack described below is the direction of travel, not the current average.

### OAuth 2.1 as the baseline

OAuth 2.1 is the consolidation of fifteen years of OAuth 2.0 errata and security best practice into a single, opinionated specification. The current version is [draft-15](https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/15/), which expires in September 2026. Despite the draft status, the MCP specification and every major vendor in the list above treat OAuth 2.1 as the baseline for new deployments. The [oauth.net/2.1 overview](https://oauth.net/2.1/) is a good primer. In parallel, [RFC 9700 (OAuth 2.0 Security Best Current Practice)](https://datatracker.ietf.org/doc/rfc9700/) captures the consolidated security guidance that OAuth 2.1 pulls in.

What OAuth 2.1 consolidates:

- **[PKCE](https://clerk.com/glossary/code-exchange-pkce.md) is required for all authorization code flows**, public and confidential clients alike.
- **Implicit flow is deprecated.** The browser-based implicit grant is removed.
- **Resource Owner Password Credentials (ROPC) is deprecated.**
- **Strict redirect URI matching** — no substring or pattern matching.
- **Refresh tokens for public clients must be sender-constrained or single-use.**
- **Bearer tokens are banned from URL query strings** — they belong in the `Authorization` header.

Pick the grant that matches the call pattern. **Client credentials** is the grant to use for pure machine-to-machine calls where no end user is present — for example, a backend agent calling an internal API under its own identity. Access tokens should be short-lived, scoped to the minimum permissions needed, and audience-constrained to a specific resource server. Prefer JWT client assertions over long-lived client secrets.

**Authorization code with PKCE** is the grant for delegated agent access, where a user has authorized the agent to act for them. Here it matters whether the agent is _impersonating_ the user (holding the user's token) or the user is effectively _logged in as the agent_ with a distinct delegated token that carries actor information. The latter is the preferred model and is what token exchange enables. [Curity's PKCE explainer](https://curity.io/resources/learn/oauth-pkce/) is a solid introduction if PKCE is new to your team.

### Token exchange and delegated agent access (RFC 8693)

[RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) defines OAuth 2.0 Token Exchange — the ability to swap one token for another with narrower scope, a different audience, or a different subject. This is the standards-native primitive for delegated agent access.

When a user hands an agent permission to call a downstream API, the agent does not reuse the raw user access token. It exchanges that token at the authorization server for a new token with a narrower scope, a specific audience, and an `act` claim identifying the agent as the actor. As the request propagates through a chain of tools, each hop can exchange again and further narrow scope. The resulting delegation chain is visible in the token itself.

The `act` and `may_act` claims are the auditability layer. `act` records who performed the action (the agent), while the `sub` claim records on whose behalf (the user). `may_act` lets a token declare which actors are permitted to delegate against it. Together they give a compliance reviewer a single token they can introspect to answer "which agent did what, for whom, when."

Use token exchange when the agent acts for a human user. Use a fresh `client_credentials` token when the agent is operating autonomously under its own identity. The two patterns coexist — a user-delegated flow can still spawn M2M sub-calls that use client credentials for infrastructure calls that have no user context.

Auth0 productized a related async pattern under [Asynchronous Authorization for AI Agents](https://auth0.com/ai/docs/intro/asynchronous-authorization), which combines Client-Initiated Backchannel Authentication (CIBA) with Rich Authorization Requests (RAR) to let an agent request a specific, semantically-rich authorization from the user out-of-band — for example, "approve this agent to transfer up to $50 from account X."

### Scoped, short-lived tokens for AI agents

Industry guidance has converged on two properties for agent tokens: narrow scopes and short lifetimes. The SuperTokens [auth-for-AI-agents guide](https://supertokens.com/blog/auth-for-ai-agents) recommends capability tokens in the 60-to-300-second range for individual tool calls, refreshed as needed. The reasoning: an agent token that leaks is far less dangerous if it expires before an attacker can chain it into a larger exploit, and narrow scopes mean even a valid stolen token is bounded in what it can do.

**Audience restrictions** (`aud` [claim](https://clerk.com/glossary/claim.md)) prevent a token issued for one API from being replayed against another. A calendar-scoped token should not be accepted by the payments API, even if both sit behind the same authorization server. [RFC 8707 Resource Indicators](https://datatracker.ietf.org/doc/html/rfc8707) is the standards mechanism: the client sends a `resource` parameter on the authorization and token requests, and the authorization server binds the resulting token to that resource via the `aud` claim. In multi-tenant deployments this is also how you tenant-isolate tokens — the resource indicator carries the tenant-specific API URL.

**Confidential vs public clients** matters for agent deployments. A backend service running in a trusted environment can be a confidential client and hold a real secret. An agent running in a user-controlled environment (an IDE plugin, a desktop app) is a public client and cannot — it uses PKCE plus sender-constrained tokens to compensate.

**Sender-constrained tokens** bind the token to a client-held key so that a stolen token is useless without the matching key. [DPoP (RFC 9449)](https://datatracker.ietf.org/doc/html/rfc9449) — Demonstration of Proof-of-Possession — is the HTTP-layer mechanism. The client signs a JWT over each request with its private key, and the resource server checks the proof against a key thumbprint baked into the access token. This is particularly valuable for public-client agents where the token is more exposed.

### Model Context Protocol (MCP) authentication

MCP is the protocol AI agents use to discover and call external tools. Its authorization story matured significantly in late 2025 and early 2026, and it is worth separating three concepts to avoid slippage.

**(a) What the spec actually requires.** The live MCP authorization specification is [revision 2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization). It opens with a stance worth quoting directly:

> Authorization is OPTIONAL for MCP implementations.

The spec then splits requirements by transport:

- HTTP-based transports SHOULD conform to the MCP authorization specification.
- stdio transports SHOULD NOT conform — they retrieve credentials from the environment.
- Other transports MUST follow established security best practices for their protocol.

When an MCP deployment _does_ implement authorization over HTTP, the spec requires the following. Authorization servers MUST implement **OAuth 2.1**. MCP clients MUST implement **PKCE with S256**, and they MUST refuse to proceed if an authorization server's metadata does not advertise `code_challenge_methods_supported`. Clients MUST send the **`resource` parameter** (RFC 8707 Resource Indicators) on every authorization and token request, regardless of whether the server is known to support it. MCP servers MUST expose [**RFC 9728 Protected Resource Metadata**](https://datatracker.ietf.org/doc/rfc9728/), and clients MUST support both discovery mechanisms — the `WWW-Authenticate` header and the `.well-known/oauth-protected-resource` document. MCP servers MUST validate the **token audience** against their own resource URI.

**(b) Optional extensions.** [Dynamic Client Registration](https://clerk.com/glossary/dynamic-client-registration.md) ([RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591)) is **MAY, not MUST**, and the spec is explicit that DCR is retained _"for backwards compatibility with earlier versions of the MCP authorization spec."_ The preferred pattern for first-time client registration is **Client ID Metadata Documents (SHOULD)**. The priority order for client registration is pre-registration, then CIMD, then DCR, then a user prompt.

**(c) Current ecosystem practice.** MCP clients ship inside Claude, ChatGPT, VS Code, Cursor, Windsurf, Zed, and Codex — see [modelcontextprotocol.io](https://modelcontextprotocol.io) for the current directory. Remote MCP servers with OAuth-based authorization are documented and in production at [WorkOS AuthKit](https://workos.com/docs/authkit/mcp), [Stytch Connected Apps with the OpenAI Apps SDK](https://stytch.com/docs/guides/connected-apps/mcp-server-overview) (see also Stytch's [guide to authentication for the OpenAI Apps SDK](https://stytch.com/blog/guide-to-authentication-for-the-openai-apps-sdk/)), [Descope Agentic Identity Hub](https://docs.descope.com/agentic-identity-hub/mcp-servers), and [Scalekit MCP Auth](https://docs.scalekit.com/). On the open-source side, [`mcpauth/mcpauth`](https://github.com/mcpauth/mcpauth) (TypeScript) and [`giantswarm/mcp-oauth`](https://github.com/giantswarm/mcp-oauth) (Go) implement the authorization-server side — token issuance and dynamic client registration. By contrast, [`NapthaAI/http-oauth-mcp-server`](https://github.com/NapthaAI/http-oauth-mcp-server) is a reference MCP server that proxies OAuth to an upstream authorization server such as Auth0 rather than implementing one itself — its README is explicit that it "does not implement an OAuth authorization server."

Clerk ships a remote MCP server at `mcp.clerk.com/mcp` that serves up-to-date Clerk SDK snippets to AI coding assistants — see the [Clerk MCP server changelog entry](https://clerk.com/changelog/2026-01-20-clerk-mcp-server.md) and [Clerk's MCP guide](https://clerk.com/docs/guides/ai/mcp/clerk-mcp-server.md). This is a vertical MCP server for Clerk documentation, not a general-purpose MCP authorization server for third-party MCP clients. Teams that want to stand up their own MCP server with Clerk-backed authentication should follow the [build-your-own MCP server guide](https://clerk.com/docs/expressjs/guides/ai/mcp/build-mcp-server.md).

### Common patterns for authenticating AI agents accessing APIs

Three patterns cover the large majority of real agent deployments.

**Pattern 1: Machine-to-machine tokens for service agents.** The agent has its own identity and there is no human in the loop. The canonical example is a backend summarization agent calling an internal search API. Use OAuth 2.1 client credentials, a JWT client assertion instead of a long-lived client secret, a tightly-scoped and audience-bound access token, and short lifetimes. Pseudocode illustrating the flow:

```ts
// Pseudocode: M2M token for a service agent
const { access_token } = await authServer.clientCredentials({
  client_id,
  client_assertion, // JWT client assertion, not a long-lived secret
  scope: 'search:read',
  audience: 'https://api.internal/search',
})

await fetch(url, {
  headers: { Authorization: `Bearer ${access_token}` },
})
```

Concrete, shipping implementations of this pattern include [Clerk's machine-to-machine tokens](https://clerk.com/docs/guides/development/machine-auth/m2m-tokens.md) (JWT format, verifiable locally without a network round trip) and [WorkOS M2M Applications](https://workos.com/docs/authkit/connect/m2m), which use the OAuth `client_credentials` grant.

**Pattern 2: Delegated user access for user-initiated agents.** The agent acts on behalf of an authenticated user, and the agent's token is derived from the user's session via token exchange or a Rich Authorization Request — not by re-using the user's raw access token. The canonical example is a productivity assistant reading a user's calendar. The resulting token carries an `act` claim that identifies the agent as the actor while the `sub` still identifies the user. Pseudocode for the token exchange:

```ts
// Pseudocode: token exchange to obtain a narrower agent token
const agentToken = await authServer.tokenExchange({
  grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange',
  subject_token: userAccessToken,
  subject_token_type: 'urn:ietf:params:oauth:token-type:access_token',
  actor_token: agentAssertion,
  actor_token_type: 'urn:ietf:params:oauth:token-type:jwt',
  scope: 'calendar:read', // narrowed
  audience: 'https://api.example.com/calendar',
  // resulting token carries an `act` claim identifying the agent
})
```

For a concrete implementation of this RFC 8693 exchange, see [Auth0's Custom Token Exchange](https://auth0.com/docs/authenticate/custom-token-exchange), which runs the token-exchange grant on its OAuth token endpoint.

**Pattern 3: Agent identity with auditable action trails.** Every call carries both the agent identity (via `act` or `azp`) and the principal it acts for (via `sub`). The resource server logs `sub`, `azp`, `act`, the request path, the scopes exercised, and the request metadata. Downstream SIEM and compliance tooling queries this log to answer "which agent did what, for whom" without having to join across multiple systems. This pattern is the operational complement to Patterns 1 and 2 — it is what makes the delegation chain useful after the fact.

### Open questions in agent authentication

The standards are moving faster than most production deployments. A few of the open questions worth tracking:

**Consent UX for long-running agents.** A multi-step agent that runs for hours or days needs a consent model that does not re-prompt the user on every tool call but also does not silently escalate. Re-prompt timing and scope-change triggers are an unsolved UX problem.

**Revocation propagation.** When a user revokes an agent's access mid-task, how quickly does that propagate through in-flight tokens at downstream resource servers? Microsoft's Continuous Access Evaluation (CAE) is a productized near-real-time revocation pattern for this class of problem. Short token lifetimes are the simpler answer, but they do not fully close the window.

**Agentic identity management.** Provisioning, rotating, and deprovisioning agent identities at scale is still mostly manual. The Strata 18% governance-confidence number is the symptom.

Emerging work worth watching:

- **Fine-grained authorization** via policy engines — Oso, Amazon Verified Permissions built on Cedar, and attribute-based access control (ABAC) more generally. Tokens carry identity; policy engines decide what that identity is allowed to do against specific resources.
- **Workload identity** — the IETF's [WIMSE architecture draft](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) is standardizing identity for workloads, drawing on prior art such as the CNCF's SPIFFE/SPIRE, which the WIMSE working group collaborates with. SPIFFE/SPIRE is the de facto operational standard for workload identity today, used by HashiCorp Vault's SPIFFE auth method and Red Hat's SPIRE-based Zero Trust Workload Identity Manager for agent identity in infrastructure.
- **[OIDC-A](https://arxiv.org/html/2509.25974v1)** — a research direction for an OIDC profile tailored to agents.
- **[Agentic JWT](https://arxiv.org/html/2509.13597v1)** — a research proposal for JWT semantics that encode agent actor chains natively.
- **Rich Authorization Requests (RFC 9396)** — structured, semantically-rich authorization requests for agent actions like "transfer up to $X to account Y."
- **FAPI 2.0** — a concrete profile that mandates DPoP or mTLS for financial-grade agent integrations.
- **CIBA (OpenID CIBA Core 1.0)** — human-in-the-loop asynchronous authorization, suited to out-of-band approvals for sensitive agent actions.
- **NIST AI Agent Standards Initiative (February 2026)** — early U.S. government standards work on agent identity and interoperability.
- **Stripe's agentic commerce and Machine Payments Protocol** — an early agent-to-service payment standard with authorization primitives built in.

The through-line across this list is that standards bodies, research labs, and commercial identity vendors are all working on the same problem: giving agents their own identity, binding that identity tightly to scope and audience, and keeping the human principal visible through the chain. The next section turns to where that authentication has to happen — at the edge.

## Conclusion

AI agents require authentication primitives that separate their actions from the human users they serve. With OAuth 2.1, token exchange, and the Model Context Protocol (MCP) becoming the baseline, developers now have the tools to issue scoped, short-lived, and auditable credentials for agentic workflows. In the next part of this series, we will explore where this verification happens by diving into edge-centric ingress verification.

## FAQ

**Can an AI agent just use my regular session token?**\
No. Reusing a human session token for an agent breaks auditability, prevents granular revocation, and typically grants the agent far more permissions than it needs for a specific task.

**What is the difference between a service agent and a delegated agent?**\
A service agent operates autonomously under its own identity (using machine-to-machine tokens), while a delegated agent acts on behalf of a specific human user (using tokens derived via token exchange).

**Is MCP authorization mandatory?**\
No, the MCP specification makes authorization optional. However, when implemented over HTTP, it strongly recommends following OAuth 2.1 and using PKCE for secure delegation.

## In this series

1. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge.md)
2. **Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 2** (you are here)
3. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 3](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge-3.md)
4. [Authentication Trends in 2026: Passkeys, AI Agents, and Edge - Part 4](https://clerk.com/articles/authentication-trends-in-2026-passkeys-ai-agents-and-edge-4.md)