Three identity vendors shipped the same agent access pattern in eight days
Okta, Auth0, and Descope all shipped Cross App Access between August 24 and September 1. The two-layer pattern underneath it outlasts whichever vendor wins.
Okta made Agent SSO generally available on August 24, folding Cross App Access into the identity product it says more than 20,000 customers use. Auth0 moved the requesting-app half of Cross App Access out of beta and into early access on August 31. Descope announced ID-JAG validation and issuance on September 1. Three companies that compete head to head for the same enterprise deal shipped the same handshake in eight days.
What they shipped matters more than the order they shipped it in. Enterprise agent access has settled into two layers that no vendor owns: a Client ID Metadata Document establishes which piece of software is calling, and an ID-JAG token exchange lets the customer's identity provider decide which applications that software may reach. If that reading holds, the first decision facing a B2B engineering team isn't which identity vendor to standardize on. It's whether your own authorization server speaks the pattern at all.
Eight days, three launches
The three announcements land on different parts of the same flow.
Okta's is the distribution event. Agent SSO ships inside core Okta SSO plans at no additional cost, with the broader Okta for AI Agents product sold separately. Okta scopes it narrowly on purpose, describing it as answering one question: how do Cross App Access agents connect to enterprise applications and MCP servers. The Okta Integration Network carries out-of-the-box support for Anthropic (Claude), Archestra.AI, Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, MintMCP, Notion, Slack, and Supabase.
Auth0's is the completion of a set. Resource-app support went to open early access on July 27, letting an API accept assertions minted elsewhere. The August 31 release promotes the other role out of beta, so an Auth0 tenant can now request an ID-JAG on a user's behalf as well as redeem one. It runs on Auth0 Token Vault over the ID-JAG protocol. On the requesting side it currently works over OIDC and Okta Workforce connections; the resource side accepts both SAML and OIDC enterprise providers.
Descope's is the one aimed squarely at B2B software teams. It supports ID-JAG validation and issuance together, and it adds self-service XAA setup to the same suite that already carries SSO, SCIM, and JIT provisioning, so a tenant admin can pick their identity provider, establish trusted issuers, register agents, and map user attributes through a guided flow. Rishi Bhargava, Descope's co-founder, framed the demand side in the release:
"Every B2B company shipping an MCP server is about to hear the same question from its enterprise customers: can we govern agent access to this MCP server with our own identity provider?"
That is the question every B2B vendor with an MCP server is about to get asked. Three identity platforms answered it the same week, with the same two specs.
The two layers agent access settled on
Client identity and delegation are separate problems, and the industry spent the last year discovering they need separate answers.
Client identity is the CIMD layer. The MCP 2026-07-28 spec deprecated Dynamic Client Registration in favor of Client ID Metadata Documents, keeping DCR only for backward compatibility. DCR credentials are keyed to the authorization server that issued them and have to be re-registered when it changes, while a CIMD client ID is a self-hosted HTTPS URL any authorization server can resolve on demand, and that portability is the whole reason for the deprecation. Enterprise-managed auth then makes it load-bearing: the identity provider stamps a fixed client_id into every assertion, and your server has to already recognize it before the first assertion arrives, which is what rules out a client that registered itself on the fly.
August was CIMD's month on the vendor side. Okta shipped agent registration by CIMD as a research release on August 5, where admins register a URL, developers control authentication at that endpoint, and Okta authenticates agents at runtime without storing credentials. Clerk shipped CIMD as a beta on August 6. Auth0 had already made CIMD registration part of the Auth for MCP GA in May. On the client side, VS Code, MCPJam, ChatGPT, and Claude Code all publish metadata documents.
Delegation is the ID-JAG layer, and it's where the enterprise gets its controls. In Auth0's own walkthrough the identity provider is the policy enforcement point: it mints the assertion only if the admin's policy allows that requesting app to reach that resource app for that user, and it can scope down the requested scopes on the way through. The two layers meet in a single claim, since in that same walkthrough the client_id inside the ID-JAG is a CIMD identifier, which is a property of how that example registers its client rather than something the protocol requires.
The division of responsibility underneath is conservative. The ID-JAG draft keeps the resource authorization server as the issuer of access tokens for its own protected resources, and that server decides whether to honor an assertion, what scopes to grant, and what token to issue under its own local policy. Auth0 describes the payoff for the app team plainly: the API validates the resulting token exactly as it validates any other, so the API code doesn't change and never learns that XAA was involved.
The pattern outlasts any one vendor's network
The obvious counterargument is that this is Okta's protocol wearing an open-standards coat. Okta led the design, Okta owns the integration network where the connectors live, and Anthropic's enterprise-managed auth for MCP connectors reached GA on August 24 with Okta the only supported identity provider, as it has been since the June beta. From a buyer's chair, the pattern and the Okta catalog can look like the same object.
This week's launches argue otherwise. Descope's validation path lets an organization register a trusted issuer per tenant and accept assertions from Okta, Ping, and other standards-compliant providers. Auth0's requesting app works over generic OIDC connections as well as Okta Workforce ones. And the official MCP SDKs are adopting XAA natively as the Enterprise-Managed Authorization extension, which is how a pattern stops being a product feature.
Check the SDK repositories before you promise anything to a customer, because the coverage is uneven and not in the direction the original roadmap implied. When Okta announced the SDK work in late 2025, it said support would start with TypeScript and Java. TypeScript shipped. So did Python and C#, the latter being what Okta's own developer blog demonstrated this summer. The Java SDK's enterprise-managed authorization pull request was closed unmerged and marked wontfix. If your MCP server is written in Java, the native SDK path is the one that isn't there, and you are implementing the exchange yourself.
The stakes for guessing wrong aren't architectural elegance. Okta's own research puts the share of organizations applying the same security controls to AI agents as to human workers at 34%. Descope cites 2026 Gravitee research finding that only 22% of teams treat agents as independent identities, with most relying on shared API keys. The alternative to this pattern isn't a better pattern. It's the API key sitting in a .env file six months after the person who generated it left the company.
The pieces that don't require a bet
WorkOS ships the neutral half of this, and has for a while.
WorkOS Connect has read URL-style client_ids, resolved the metadata, and rendered the matching consent screen since November 30, 2025, well before the MCP 2026-07-28 spec named CIMD as DCR's replacement. It is off by default and enabled under Connect and then Configuration. AuthKit accepts ID-JAG assertions from enterprise identity providers in early access today, handling JWKS signature verification, audience and claims validation, policy enforcement, and scoped token issuance. And auth.md, the open agent-registration protocol we authored, went live inside AuthKit as Agent Registration on August 4; its reference implementation is MIT licensed and needs no WorkOS account to publish or read.
None of that requires an opinion about which identity provider your customer bought. That is what falls out of building against the spec instead of one vendor's SDK. WorkOS is named among the identity infrastructure and gateway partners in Okta's Cross App Access partner announcement from June, and the same code works against a customer running Ping or Keycloak, because the trust relationship is a per-tenant issuer configuration inside your product rather than a vendor selection.
Two companion posts cover the builder's half in detail. Your app is the other half of agent SSO walks through the resource-app side: what lands on your token endpoint, the validation checks that aren't negotiable, and why subject resolution is the part that touches your data model. Enterprise-managed auth is GA and your MCP server needs a new grant type covers what your authorization server has to accept once the consent screen stops rendering. If the client-identity layer is the open question, the comparison of DCR, CIMD, and auth.md is the one to read.
What to decide this quarter
The vendor news is a signal about timing, not a shopping list. Three identity platforms shipping the same two specs in eight days means enterprise buyers now have a name for the thing they're going to ask you for, and a console in which to ask it.
So decide one thing: whether an enterprise admin can point an agent at your product next quarter and have it work without a per-user consent screen and a long-lived API key. The first move is four lines of RFC 8414 metadata, because a client reads grant_types_supported to decide whether to offer the enterprise flow at all:
After that it's resolving client IDs you didn't issue, and keeping a per-tenant allowlist of the issuers you trust. None of it is a bet on one vendor's platform. All of it is a prerequisite for joining any of them.