Four identity vendors will sell you "auth for AI agents" and mean two incompatible things by it. One is letting somebody else's agent into your application with a scoped, revocable token; the other is letting your agent out to Gmail or Salesforce holding a credential that belongs to your user. Most agent products need both, no vendor page tells you which half it is, and the choice is nearly irreversible because it lands in your data model. Pick on direction, then on whether you can adopt a platform — and be honest that a vault storing a user's full grant has relocated the credential rather than shrunk it.
At a glance
Four platforms, sorted by the direction each one leads with rather than by feature count.
| Platform | Leads with | Shape | Best fit |
|---|---|---|---|
| Auth0 for AI Agents | Outbound — Token Vault, plus async approval via CIBA and PAR | A full CIAM platform with agent features layered on; GA since November 2025 | Teams already on Auth0, or willing to adopt it, building an agent that acts on users' third-party accounts |
| Descope | Both — Inbound Apps and Outbound Apps as separate named products | Visual flow orchestration; 50+ outbound integration templates; retrieval gated by an access-control plane | Products that need both directions and want them from one vendor with one mental model |
| Stytch Connected Apps | Inbound — your app becomes an OAuth 2.1 provider | PKCE, Dynamic Client Registration, drop-in consent UI; runs standalone over an existing CIAM. Twilio completed its acquisition in November 2025 | An existing user base you will not migrate, and an MCP server you need to expose next month |
| WorkOS AuthKit / Connect | Inbound — MCP-compliant authorization server, GA since May 2026 | AuthKit flips to an MCP OAuth 2.1 server with one config value; Connect runs as middleware in front of your existing identity system | B2B SaaS with enterprise SSO already solved, adding agent access without touching the login box |
The two directions, and why conflating them costs you
Inbound is your application becoming an OAuth authorization server. Someone else's agent — a chat client, an MCP host, a partner's automation — wants to reach your users' data. The hard parts are that the client has no browser session, may have registered itself dynamically thirty seconds ago, and needs a token narrow enough that you would be comfortable with it leaking. MCP is what made this urgent for everybody at once, and it is why all four vendors are strong here.
Outbound is your agent needing a credential that belongs to your user, for a service you do not own. The hard parts are storage, refresh before expiry, requesting an additional scope mid-task without restarting the conversation, and deciding which of your own components may retrieve a token at all. This is a vault problem and it looks nothing like the first one.
The conflation is expensive because the two land in different places in your system. Inbound is a property of your API surface; you can add it late, and Stytch and WorkOS both exist precisely so you can add it late without touching your incumbent identity provider. Outbound is a property of your data model — which user, which connection, which scopes, which agent run, which retrieval policy — and retrofitting it means rewriting how every tool in your agent gets its credentials.
The practical test, before you read any pricing page: write down the sentence "an agent needs a token to…" for your product. If the sentence ends "…reach our data", you have an inbound problem. If it ends "…reach the user's Google account", you have an outbound problem. If you wrote both, you need a vendor that names both, or two vendors and a clear boundary between them.
Where each one is genuinely strongest
Auth0: the outbound story is the most complete, and it comes with a platform
Token Vault holds OAuth credentials for third-party tools and handles the refresh and exchange machinery you would otherwise write twice and get wrong once. Async Authorization is the piece that stands out: using CIBA and PAR, an agent can pause mid-task, request a human approval out of band, and resume — which is the mechanism a long-running agent needs and the one most teams end up hand-rolling with a database table and a polling loop. Generally available since November 2025, with two connected apps in the free tier, which is enough to build against rather than merely to demo.
The cost is the shape of the commitment. Auth0 is a full customer identity platform, and adopting its agent features most comfortably means adopting the platform. That is a fine trade if you are already there and an expensive one if your users live somewhere else.
Descope: the only one that names both halves as products
Inbound Apps turn your APIs into an OAuth server for agents with custom scopes; Outbound Apps are a token vault with more than fifty integration templates — Gmail, HubSpot, GitHub, Snowflake, Slack, Notion, Shopify — and, more interestingly, an access-control plane governing which agents and users may retrieve a token for a given connection at all. That last control is the one detail on any of these pages that is aimed at the actual agent threat model rather than at the OAuth spec: it assumes a compromised or confused component inside your own system.
If you are building a product where users connect their own tools and your agent then acts on them, this is the closest fit, and the reason is that you get one mental model across both directions instead of two integrations that disagree about what a "connection" is.
Stytch: standalone inbound over an identity system you are not replacing
Connected Apps turns your application into an OAuth 2.0/OIDC provider — OAuth 2.1 with PKCE, Dynamic Client Registration, a drop-in consent UI, and full lifecycle management of grants. The decisive property is that it can operate as a layer on top of an existing CIAM without migrating your user database, which converts "we need to expose an MCP server" from a quarter of identity work into an integration. Twilio completed its acquisition of Stytch in November 2025, which is worth knowing for roadmap reasons rather than technical ones.
WorkOS: the least invasive way to become an MCP authorization server
AuthKit becomes an MCP-compliant OAuth 2.1 authorization server with a single configuration value, and Connect is the standalone path — middleware in front of your existing identity system that handles only the MCP OAuth flows: discovery endpoints, dynamic client registration, PKCE, token issuance, consent. Auth for MCP went generally available in May 2026, including client ID metadata registration and on-behalf-of token exchange. If your enterprise SSO and SCIM are already solved and you simply need agents to be able to authenticate, this is the smallest diff.
The axis nobody sells on: how small is the token?
Here is the thing worth carrying away from any of these products. The identity layer is the one agent control that keeps working after prompt injection has already succeeded, because it is enforced outside the model — an agent that has been talked into trying something it should not do still cannot do what its token does not permit. That is the whole reason this category matters more for agents than it did for apps.
But it only pays out in proportion to how narrow the token is, and the default everywhere is a token scoped to the user's grant. Your agent asks to draft one reply; it holds a credential that can read the entire mailbox and send as the user, because that is what the OAuth consent screen offered and what the vault stored. The vault has moved the credential out of your process — genuinely valuable, and not nothing — but the blast radius after a successful injection is unchanged.
Three things follow, and none of them is on a pricing page.
Ask for the narrowest scope the provider offers, then narrow again in your own middleware. Providers vary enormously in scope granularity and you inherit their ceiling. Where the ceiling is too high, the only remaining control is a proxy of your own that enforces per-task limits on top of the vendor token — which is the same argument, at the network layer, as in egress control for agents.
Treat retrieval as an authorization decision, not a lookup. Which agent, on whose behalf, for which task, gets to pull this token out of the vault? Descope's access-control plane makes this explicit; wherever it is not explicit, it defaults to "any code holding the SDK".
Test revocation before you need it. Revocation is the strongest thing this layer gives you and the least exercised. Can you kill one agent's access without logging the user out? Can you kill one connection without killing the others? If the answer to either is no, you have a lower-resolution kill switch than you think — see kill switches for what it needs to actually stop.
When to pick which
| Situation | Pick | Because |
|---|---|---|
| Exposing an MCP server, existing identity provider staying put | WorkOS Connect or Stytch Connected Apps | Both are designed to sit in front of an incumbent without a user migration |
| Agent acts on users' Gmail, Slack or Salesforce | Auth0 Token Vault or Descope Outbound Apps | Storage, refresh and incremental scope requests are the actual work, and both ship it |
| Long-running agent that must pause for human approval | Auth0 | CIBA and PAR are first-class rather than something you assemble |
| Both directions, one vendor, one model of a “connection” | Descope | Inbound and Outbound Apps are separate products under one platform |
| B2B SaaS where enterprise SSO and SCIM already dominate the requirements | WorkOS | Agent access becomes a configuration change rather than a project |
One caution that applies to all four: this category is moving fast enough that the two middle rows of the matrix above will have changed by the time you read a procurement deck about them. The direction split is durable; the feature list is not. Verify the outbound and async-approval rows against current documentation, and weight anything you find in a comparison article — including this one — accordingly.
FAQ
What is the difference between inbound and outbound agent authorization?
Inbound means your application acts as an OAuth authorization server so an external agent or MCP client can obtain a scoped, revocable token to reach your users' data. Outbound means your own agent obtains a credential belonging to your user in order to call a third-party API such as Gmail or Salesforce. They are opposite flows with different hard problems — consent and dynamic client registration on one side, token storage and refresh on the other — and most agent products need both.
Which of these platforms handles outbound tokens?
Auth0 for AI Agents ships Token Vault, and Descope ships Outbound Apps with more than fifty integration templates and an access-control plane governing which components may retrieve a token. Stytch Connected Apps and WorkOS both lead with the inbound half — becoming an OAuth authorization server for agents — rather than with a vault.
What is CIBA and why does an agent need it?
Client-Initiated Backchannel Authentication lets an application request a user's approval out of band, without a browser redirect. For a long-running agent this is the mechanism that allows a task to pause for human consent and then resume, instead of failing because nobody was present at the moment the token was needed. Auth0 exposes it as a first-class async authorization feature.
Can I add agent auth without replacing my identity provider?
Yes for the inbound half. WorkOS Connect runs as middleware in front of an existing identity system and handles only the MCP OAuth flows, and Stytch Connected Apps can operate as a standalone layer over an existing CIAM without migrating your user database. The outbound half is harder to bolt on because it lands in your data model rather than at your API edge.
Does a token vault reduce the risk from prompt injection?
Partly. It moves the credential out of your agent's process, which is real value, but the token it stores is usually scoped to whatever the user granted on the consent screen — often full read and write on a whole account. After a successful injection the reachable surface is the token's scope, not the task's, so the vault has relocated the credential rather than shrunk it. Narrowing scope per task, and treating retrieval from the vault as its own authorization decision, is what actually reduces blast radius.
What should I test before committing to one?
Revocation, at the resolution you will need it. Try killing a single agent's access without logging the user out, and a single third-party connection without affecting the others. Also test an incremental scope request in the middle of a running task, since that is the flow that most often turns out to require restarting the user's session.
Further reading
On this wiki:
- Agent Identity & Permissions — why authentication, authorization and attribution are three questions.
- Scoped Credentials for Agents — narrowing the token to the task.
- MCP Auth & OAuth 2.1 — the protocol these inbound products implement.
- Agent Identity — the operational side, including revocation.
- A2A v1 — what changes when the caller is another agent rather than a client.
- Prompt Injection — the attack this layer still holds against.
Project sources:
- Auth0 for AI Agents is now generally available — Auth0
- Outbound Apps: Connect AI Agents With External Tools — Descope
- Connected Apps: auth for AI agents and MCP that fits your existing identity stack — Stytch
- Model Context Protocol — WorkOS AuthKit docs
- Best Authentication Platforms for AI Agents and MCP Servers in 2026 — MarkTechPost