Everyone Selling AI Agent Auth Solves Login. Almost None of Them Solve Delegation.

For the last two years, "auth for AI agents" meant picking your favorite OAuth provider, wiring up a token, and hoping for the best. That casualness ended on July 28, 2026. The Model Context Protocol — the spec that decides how agents talk to tools — shipped its biggest revision since launch, and buried inside the session-model rewrite was a much bigger change: MCP servers are now formally required to behave like OAuth 2.1 resource servers. Discovery, token audience-binding, dynamic client registration — all of it moved from "nice to have" to "must implement."

That single spec change turned a UX decision into an infrastructure decision, and it's why three companies that used to sell fairly interchangeable login boxes are now shipping distinctly different answers to the same question: how does an autonomous piece of software prove who it is, and who it's acting for?

This piece compares WorkOS AuthKit, Auth0 for AI Agents (Okta), and Stytch Connected Apps — the three vendors positioning themselves as MCP-compatible identity providers — plus a fourth category that gets confused with them constantly: Composio, which solves a related but genuinely different problem. If you're picking one of these right now, the differences matter more than the marketing pages make them look.

Why this is a live decision, not a hypothetical one

The numbers behind this shift are not speculative. MCP's combined Python and TypeScript SDK downloads crossed 97 million a month by late 2025, less than 18 months after Anthropic released the protocol. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation — a governance move usually reserved for infrastructure people expect to depend on for a decade. Gartner is projecting that up to 40% of enterprise applications will ship an integrated, task-specific AI agent by the end of 2026, up from under 5% a year earlier.

Scale like that changes what "identity" means. The Cloud Security Alliance's May 2026 whitepaper put the ratio of non-human identities to human users at 45:1 across the average enterprise, climbing to 144:1 in cloud-native environments. Most of that growth is now agents, not the service accounts and cron jobs that used to dominate the count. And unlike a service account, an agent doesn't execute a fixed code path a developer reviewed before shipping — it reasons at runtime, decides which tools to call, and can produce a different sequence of actions from the same prompt on two different days. You can't audit that the way you audit a microservice's permission set, because the permission set an agent uses on a given run isn't fully knowable at provisioning time.

Before July 28, MCP's answer to this was, in the words of one vendor's own retrospective, "bring your own token." The 2025-11-25 spec introduced OAuth 2.1 as an option; the 2026-07-28 spec makes it a requirement. MCP servers now must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the correct authorization server automatically, and MCP clients must implement Resource Indicators (RFC 8707) so a token minted for one MCP server can't be replayed against another — closing a token-confusion hole that was theoretically exploitable under the old spec. Dynamic Client Registration is no longer the default path either; the spec now prefers OAuth Client ID Metadata Documents (CIMD), with DCR demoted to an optional fallback.

None of this is abstract compliance trivia. If you're standing up a remote MCP server today, whether your auth layer satisfies these MUST-level requirements out of the box — versus something you bolt on yourself — determines whether you ship in a sprint or spend a quarter building an authorization server from spec text.

What each option actually is

It's worth separating these upfront, because the four names get lumped together in comparison threads despite doing different jobs.

WorkOS AuthKit is the product of a company that has, since 2020, positioned itself as an independent enterprise-identity layer you bolt onto an app without replacing your user database. AuthKit can act as an OAuth 2.1 authorization server for MCP servers directly against the official MCP SDKs, and it sits alongside the rest of WorkOS's stack: Enterprise SSO, SCIM directory sync, an Admin Portal for IT teams to self-serve their own SSO/SCIM connections, audit logs, and Fine-Grained Authorization (FGA). The FGA piece is the one that matters most for agents specifically — it scopes permissions to individual tools rather than whole services, so an agent can be authorized to call calendar.read without inheriting blanket access to the calendar API.

Auth0 for AI Agents, from Okta, is the incumbent's answer, built on top of Auth0's existing OAuth 2.0/OIDC platform rather than a new product line. "Auth for MCP" exited early access in November 2025 and reached general availability on May 6, 2026. Its standout piece is Token Vault: an agent authenticates a user against an external identity provider (Google, Slack, GitHub, Box, or a custom OIDC connection) once, and Auth0 handles fetching and silently refreshing the tokens that let the agent call those providers' APIs on the user's behalf, without your code touching a refresh token directly. For actions that need a human to explicitly approve before an agent proceeds — a payment, a delete, an irreversible send — Auth0 supports Client-Initiated Backchannel Authentication (CIBA) and Rich Authorization Requests (RAR), which push a specific, human-readable approval request to the user's device out of band from the agent's own request flow. Auth0 FGA additionally enforces document- and relationship-level access control inside RAG pipelines, which is a distinct problem from tool authorization but one agent-heavy teams run into constantly.

Stytch Connected Apps, now under Twilio following the November 2025 acquisition close, takes a bolt-on-not-migrate posture explicitly aimed at teams with an existing, possibly legacy, identity stack. It implements OAuth 2.1 with PKCE, Dynamic Client Registration, and a drop-in consent screen, and its clearest differentiator is depth on Cloudflare. Cloudflare's Agents SDK ships an McpAgent class that handles MCP transport and auth automatically, backed by a workers-oauth-provider library implementing the full OAuth server flow for Workers deployments — and Stytch's Trusted Auth Tokens integrate with that path cleanly, making it the most edge-native option of the three for teams actually deploying remote MCP servers on Workers rather than a traditional backend.

Composio is not an identity provider and shouldn't be evaluated as a straight alternative to the other three, even though it shows up in the same comparison searches. It's an agent integration platform — managed OAuth across a large catalog of pre-built SaaS connectors, tool schema definitions, execution controls, retry logic, and rate-limit handling — where auth is one component of a broader stack rather than the product itself. If your problem is "I need my agent to safely act inside my own enterprise's IdP," Composio isn't solving that. If your problem is "I need my agent to authenticate against 60 different SaaS APIs without hand-rolling 60 OAuth integrations," it's solving a real and different problem that WorkOS, Auth0, and Stytch don't touch.

How each one is actually built

The architectural differences matter more than the feature-list differences, because they determine what breaks under load and what you can't change later without a migration.

WorkOS AuthKit is built as an additive authorization layer: it doesn't want to own your user table. Under the hood, AuthKit acts as the OAuth 2.1 authorization server MCP requires, but it delegates the actual "who is this person" question outward — to Okta, Entra ID, Google Workspace, or whatever SSO your enterprise customers already run — via standard SAML/OIDC federation, then issues MCP-scoped tokens on top of that federated identity. FGA is implemented as a separate relationship-based authorization engine (conceptually similar to Google's Zanzibar model), which is why it can express "this agent can read this specific calendar, on behalf of this specific user" as a first-class relationship rather than a flat scope string. The tradeoff is that FGA is a second system to model and operate, not a checkbox in the OAuth flow.

Auth0's architecture leans the opposite direction: centralize, don't federate. Token Vault sits inside Auth0's own infrastructure and holds the third-party tokens (Google, Slack, GitHub, Box) it exchanges on an agent's behalf, so your application code never sees or stores a long-lived third-party credential directly — Auth0 refreshes and rotates them internally. CIBA and RAR are built on the same backchannel pattern Auth0 already used for step-up MFA, repurposed for agent approval: the authorization request and the human's approval travel on a separate channel from the agent's own API call, which is what lets an agent poll for "has the human approved this yet" without blocking on a redirect the way browser-based OAuth normally requires. That backchannel-first design is precisely what makes Auth0 the strongest fit for asynchronous, non-interactive agent workflows — an agent doesn't need a browser tab open to get human sign-off.

Stytch's architecture is the most explicitly edge-oriented of the three. Trusted Auth Tokens are designed to be verified locally at the edge — inside a Cloudflare Worker, for instance — without a round trip back to a centralized Stytch server for every single request, using standard JWT verification against published signing keys. That's what makes the Cloudflare Workers fit more than a partnership announcement: Stytch's token model was built to be cheap to verify at high request volume and low latency, which is exactly the profile of an MCP server running at the edge and fielding tool calls from many concurrent agent sessions. WorkOS and Auth0's more centralized models are not disqualifying for edge deployments, but they weren't optimized for that request pattern the way Stytch's was.

What changed, concretely, since last year

Up through most of 2025, "MCP auth" was a grab-bag of static API keys, ad hoc bearer tokens, and per-implementation OAuth flows that varied server to server — workable for prototypes, a liability at production scale, and audited by nobody. Three things converged to end that:

First, the spec itself hardened. The stateless-core rewrite (removing the initialize handshake and the Mcp-Session-Id header) was the headline change developers noticed, but the authorization tightening is the one with lasting consequences: MCP servers are now OAuth 2.1 resource servers by requirement, not convention.

Second, the vendors formalized dedicated product lines instead of treating agent auth as a feature bullet. Auth0's GA in May 2026 and Okta's own MCP server (a protocol layer letting agents manage Okta itself via natural language, with least-privilege enforcement at each tool call) both landed inside a five-month window. WorkOS built out FGA specifically for tool-level agent scoping. Stytch repositioned Connected Apps around MCP explicitly rather than as a generic OAuth-as-a-service offering.

Third, the standards conversation moved beyond OAuth's original human-in-a-browser model. Microsoft's Entra Agent ID reached general availability in April 2026, treating an agent identity as a specialized service principal with its own short-lived, blueprint-issued tokens — distinct from both user identities and traditional service accounts. NIST published a concept paper on agent identity in early 2026. The IETF is working to standardize an /agents resource in SCIM so agent identities can be provisioned and deprovisioned through the same directory-sync machinery organizations already use for humans. None of that is finished. All of it signals that the current WorkOS/Auth0/Stytch generation of products is version one of a category still being defined underneath them.

Why this should matter to you, specifically

Cost. WorkOS and Auth0 both push serious functionality — FGA, in particular — behind tailored enterprise pricing rather than transparent self-serve tiers, and Auth0's FGA is an explicit add-on cost on top of the core platform, which compounds with pricing complexity left over from Okta's 2021 acquisition of Auth0 (real product overlap, not just marketing noise). Stytch is the more usage-based, self-serve-friendly of the three, though it now runs inside Twilio's billing and roadmap orbit.

Latency and operations. Stytch's Workers-native path avoids a round trip to a centralized auth server for edge-deployed MCP servers in a way WorkOS and Auth0 — built around a more traditional centralized authorization server — don't natively offer. If your MCP server runs on Cloudflare's edge, that's a real architectural fit, not a preference.

Developer experience. Auth0 ships out-of-the-box integrations with LangChain, LlamaIndex, and the Vercel AI SDK, which shortens the path from framework code to a working authorization flow if you're already in that ecosystem. WorkOS optimizes for the opposite case: minimal disruption to an org's existing identity provider, so you're integrating AuthKit alongside Okta or Entra ID rather than replacing either. Stytch's drop-in consent UI removes a genuine chunk of custom frontend work most teams underestimate until they're building their third "Allow this agent to access your calendar?" screen by hand.

Lock-in. This is where the marketing gets slippery. Stytch and WorkOS both explicitly advertise "no migration required" — you keep your existing user database and identity provider, and their product sits alongside it. Auth0's strongest pitch only holds if you're already on Auth0 or Okta; for a greenfield team, adopting Auth0 for AI Agents means adopting the rest of Auth0's platform gravity along with it, which is a heavier commitment dressed up as a feature.

Security depth. This is the part none of the three vendors' homepages lead with, and it's worth its own section.

Practical use cases, per option

WorkOS AuthKit fits a B2B platform team shipping an MCP server to enterprise customers who each run their own IdP. Concretely: a data-analytics SaaS adds an AI agent that customers can point at their own warehouse, and each customer's security team needs to see, in their own SSO/SCIM-managed environment, exactly which of their users authorized the agent, which tools it called, and to revoke that access through the same admin console they already use for every other app. AuthKit's Admin Portal is built for exactly that self-serve IT-admin workflow, and FGA lets the platform team scope the agent to specific warehouse tables rather than the whole account.

Auth0 for AI Agents fits an AI assistant that acts across a user's existing SaaS accounts with a mix of low-stakes and high-stakes actions — drafting a calendar invite versus sending a wire transfer confirmation. Token Vault handles the low-stakes, no-human-needed calls (read the calendar, check the inbox) silently in the background; CIBA/RAR handles the high-stakes ones by pushing an explicit, human-readable approval request to the user's phone before the agent proceeds. This is the shape of most consumer-facing and internal "executive assistant" agents currently shipping.

Stytch Connected Apps fits a startup building a remote MCP server meant to be called by many different AI clients (Claude, ChatGPT, a custom agent framework) at once, deployed on Cloudflare Workers for cost and latency reasons, without wanting to stand up or migrate to a full CIAM platform first. The Cloudflare Agents SDK's McpAgent class plus Stytch's Trusted Auth Tokens is close to the minimum viable path from zero to a spec-compliant OAuth 2.1 MCP server today.

Composio, as the outlier category, fits a team building an internal automation agent that needs authenticated write access to a long tail of SaaS tools — Notion, Linear, HubSpot, Slack, GitHub, and a dozen more — where the engineering cost isn't governance depth on any one of them, it's the sheer number of OAuth integrations to hand-roll and keep working as each provider's API evolves.

The gap none of them advertise clearly

WorkOS's own developer guide to agent authentication — a genuinely candid piece for a vendor blog — states plainly that "delegation chains break down at scale" and names cross-agent privilege escalation, session smuggling in multi-agent pipelines, and Confused Deputy attacks through shared service accounts as open problems, not solved ones. That's a striking admission from a company selling an agent-auth product, and it lines up with independent identity-vendor analysis: a standard OAuth token issued to a human carries broad context — role, department, the full set of apps that person can touch — which is fine when a person is using it, and dangerous when an agent inherits it wholesale. Multiple sources in the identity space describe the fix as token exchange: swapping that broad human token for a narrow, short-lived one scoped to exactly the task the agent is performing, plus an auditable On-Behalf-Of chain linking every downstream action back to the human (or agent) that authorized it.

None of WorkOS, Auth0, or Stytch sell that as a complete, out-of-the-box capability today. Auth0's Token Vault and CIBA/RAR flows get partway there for the specific case of an agent calling a third-party API on a user's behalf with human approval gates — that's real and shipped. What none of them fully solve is the harder, still-emerging problem: an orchestrator agent handing a scoped, narrowed credential to a sub-agent, which hands a further-narrowed credential to a tool call, with continuous policy re-evaluation as conditions change mid-chain (the Shared Signals Framework concept known as CAEP — Continuous Access Evaluation Profile). That's the layer Entra Agent ID and a handful of specialist identity vendors are actively building toward in 2026, and it's a reasonable bet you'll be revisiting this decision within 12–18 months as those pieces mature, independent of which vendor you pick today.

The other omission worth naming: Stytch's post-acquisition trajectory under Twilio is a real maintainability question, not FUD — even the vendor-neutral trade coverage of this space flags it directly. Auth0's FGA-as-add-on pricing and the general Auth0/Okta product-overlap complexity is a similarly under-advertised cost center. WorkOS's "tailored pricing" for anything beyond the self-serve tier means you won't know your real cost until you're deep enough into a sales conversation that switching feels expensive.

Comparison

An independent read

The July 28 spec update did real, useful work: it took MCP authorization from "every implementation invents its own thing" to a spec-enforced OAuth 2.1 baseline with standardized discovery and audience binding. That's a genuine consolidation, and it's why all three vendors here can legitimately claim MCP compatibility rather than bolting on a proprietary scheme. But "MCP-compliant OAuth" solves the login-and-consent problem — proving an agent is who it says it is, with a user's explicit permission — and that problem is now genuinely solved, multiple ways, by mature vendors.

The problem it doesn't solve is delegation depth: what happens three hops into an agent-to-agent chain, when the token that started as a narrow, human-approved grant has to be narrowed again, and again, with an audit trail that survives a security review. That's not a knock on any one vendor — it's an honest read of where the standards (Entra Agent ID, SCIM's proposed /agents resource, CAEP) still are: general availability for the primitives, early days for the composition. Buy for the login-and-consent problem you have today, but budget the assumption that the delegation layer above it is going to be a second purchase, not a checkbox these three already tick.

Who should pick what

If your organization already runs Okta or Entra ID and your agents need to call third-party SaaS APIs on a user's behalf with an approval gate for sensitive actions — an AI assistant that can draft an email but needs a human tap before it sends one, say — Auth0 for AI Agents has the most complete answer already built, at the cost of deepening your commitment to the Okta stack.

If you need enterprise SSO, SCIM, and tool-level authorization layered onto an identity provider you already run, without migrating your user base and without adopting a full IAM platform, WorkOS AuthKit is the more surgical fit — assuming you're comfortable negotiating pricing once you're past the self-serve tier.

If you're shipping a remote MCP server on Cloudflare Workers and want OAuth 2.1, DCR, and a working consent screen without owning CIAM infrastructure yourself, Stytch Connected Apps is architecturally the closest match — with the caveat of watching Twilio's product direction over the next year.

If your actual bottleneck is breadth — an agent that needs authenticated access to dozens of SaaS tools rather than deep governance over one enterprise identity graph — none of these three are the right shape, and Composio (or a similar integration-platform approach) is worth evaluating instead of forcing a fit.

And if your system involves agents delegating to sub-agents in a chain longer than one hop, treat all four of these as necessary but not sufficient. That layer of the stack is still being built, by these vendors and by dedicated identity infrastructure players, and picking a login provider today doesn't close that gap — it just tells you clearly, for the first time, exactly where the gap starts.

Discussion question: for teams already running production multi-agent systems — where one agent's output triggers another agent's tool calls — how are you actually scoping and auditing the credential handoff between agents today? Are you relying on your OAuth provider's native delegation support, building a custom token-exchange layer, or just accepting the confused-deputy risk for now?

Sources:

• The biggest MCP spec update ships July 28: What changes for AI agent authentication — WorkOS
• The developer's guide to AI agent authentication and authorization — WorkOS
• AI agent authentication methods — Stytch
• Auth0 for AI Agents — Auth0 Docs
• Best Authentication Platforms for AI Agents and MCP Servers in 2026 — MarkTechPost
• 2026 Guide to OAuth Token Exchange & Agentic AI — Strata
• Auth0 gives developers the identity layer to securely ship agentic apps — Okta Newsroom