AI Agent Identity and MCP: Authenticating Non-Human Identities

Why agent identity matters now

The trend isn't subtle. Most CIAM vendors with agent-traffic visibility report 10–30% of authentication volume now coming from agents (Descope and Auth0 customer telemetry, 2026). The pattern that stalled identity tooling for non-human entities, assuming human-grade prompts and human-paced flows, no longer matches the traffic.

What MCP is

Model Context Protocol was introduced by Anthropic in late 2024 as an open protocol for AI agents to communicate with servers exposing tools, resources, and prompts. By 2026 MCP is broadly adopted across agent frameworks and increasingly supported by infrastructure vendors.

The MCP auth profile uses OAuth 2.1:

1. The agent connects to an MCP server.
2. If the server requires auth, it returns a 401 with the authorization server URL.
3. The agent identifies itself to the authorization server: a Client ID Metadata Document URL first, Dynamic Client Registration only as fallback.
4. The agent runs the OAuth 2.1 Authorization Code flow (or Device Code flow if no browser).
5. The user grants consent, the authorization server issues a token.
6. The agent presents the token on subsequent MCP calls.

The structural decision is at step 3. Without some form of runtime client identification the agent has to be pre-registered manually, workable for a closed ecosystem, unworkable when agents are dynamic and ecosystems are open. The 2025-11-25 MCP authorization spec made Client ID Metadata Documents the preferred answer and kept DCR "for backwards compatibility." See MCP Server Identity Model for the priority order.

Dynamic Client Registration (the fallback)

DCR (RFC 7591) lets an OAuth client register itself at runtime by POSTing its metadata to a registration endpoint:

POST /oauth/register HTTP/1.1
Host: auth.example.com
Content-Type: application/json
 
{
  "client_name": "MyAgent v1.2",
  "redirect_uris": ["https://agent.example.com/callback"],
  "grant_types": ["authorization_code"],
  "token_endpoint_auth_method": "none"
}

The authorization server returns a client_id and (optionally) client_secret. The agent now has credentials it didn't have a moment ago.

The CIAM that ship DCR cleanly: Auth0, Descope, Ory, Zitadel, Curity. Several others ship partial DCR (creation works, ongoing management of dynamically-registered clients is patchy). Every DCR call writes a row to the client table, which is the sprawl problem CIMD removes.

Enterprise-managed agent access (Cross App Access)

B2B buyers want one more control: their own identity provider deciding which apps an agent may reach for which employee. That is the Enterprise-Managed Authorization pattern. The requesting app exchanges the user's ID token at the enterprise IdP for an ID-JAG, then redeems it at the resource app's authorization server. Okta made Agent SSO generally available on August 24, 2026, Auth0 moved the requesting-app half of Cross App Access to early access on August 31, and Descope announced ID-JAG issuance and validation on September 1. Treat preview features as subject to change and verify in a proof of concept.

Agent vs human token separation

The next architectural decision is whether agent tokens look identical to human-issued tokens or carry distinguishing markers. The choice has policy implications: if the system can't tell agent traffic from human traffic, it can't apply different rate limits, scope restrictions, or audit treatment to each. Most production architectures in 2026 distinguish the two, accepting the small additional complexity at issuance for materially better policy control at runtime.

Identical, simpler. The token has the user's identity and scopes; the system can't tell whether a human or an agent presented it.

Distinguished, most production architectures in 2026. The token carries claims indicating it was issued to an agent acting on behalf of a user, plus the agent's identity. Policy engines can apply different rules:

• Rate limits per agent rather than per user.
• Scope restrictions specific to agent capability.
• Audit logging that distinguishes agent traffic.
• Step-up auth for sensitive operations even when the user has consented.

The CIAM vendors with the strongest 2026 agent-vs-human separation are Descope (MCP-native), Auth0 (partial via Actions), Stytch (partial), and Ory (partial). Most other CIAM treat agent tokens as identical to human tokens.

Scope design for agents

Agents need fine-grained scopes, not blanket access. The 2026 best practice is to design scopes such that an agent can request the minimum capability needed for its task and the user can review and approve at consent time.

Bad: read:everything. Good: read:calendar:next-7-days, write:email:draft-only-no-send, invoke:workflow:specific-named-workflow.

The scope design is a CIAM concern but also a product concern, the CIAM provides the mechanism, the application defines the scopes.

Rate limiting and abuse defense

Agent traffic patterns differ from human traffic:

• Higher request rates, an agent makes API calls at programmatic speed, not user speed.
• Bursty patterns, agents process a task and pause, rather than steady human session traffic.
• Scripted access patterns, agents may iterate predictably over resources in ways humans don't.

Rate limits tuned for human traffic break agents. Rate limits tuned for agents let abusive humans run scripts that look like agents. The fix is per-token rate limits that depend on whether the token is agent-issued, with separate budgets.

Web Bot Auth

Web Bot Auth is an IETF draft (HTTP Message Signatures profile) for cryptographic bot identity at the network layer. The bot signs each request with its identity and origin servers verify the signature against a published key.

The complementary relationship with OAuth: OAuth 2.1 grants the bot permission to act, Web Bot Auth proves the request actually comes from the named bot (not an attacker spoofing the user-agent string).

Cloudflare ships support for Web Bot Auth as part of its bot management product. Broad CIAM support is still early in 2026; the standard hasn't reached final RFC status. Worth tracking; not yet a default deployment requirement.

Vendor support snapshot

The CIAM with the strongest 2026 agent-identity story:

• Descope, first-class MCP support, scoped agent tokens, agent-vs-human separation in policy engine, ID-JAG issuance and validation (announced September 1, 2026).
• Auth0, OAuth 2.1, DCR, agent token customization via Actions; Cross App Access in early access on both the resource-app and requesting-app sides (Enterprise, B2B Pro, and B2B Essential plans).
• Stytch, OAuth 2.1, partial MCP, growing agent-identity surface.
• Ory, strict OAuth 2.1 implementation, DCR, partial MCP.
• Curity, standards-purist OAuth 2.1 with strong agent / non-human identity support.

Most other CIAM treat agent identity as a roadmap concern rather than a production capability. As agent traffic grows, expect this to be the next major axis of CIAM differentiation.