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 registers itself at the authorization server via Dynamic Client Registration.
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 Dynamic Client Registration the agent has to be pre-registered manually, workable for a closed ecosystem, unworkable when agents are dynamic and ecosystems are open.

Dynamic Client Registration

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).

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.
• Auth0, OAuth 2.1, DCR, agent token customization via Actions; partial first-class agent model.
• 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.