Okta, Auth0 and Descope converge on the same AI agent access pattern within eight days

Between August 24 and September 1, 2026, three identity providers competing directly for the same enterprise customers —Okta, Auth0 and Descope— each independently launched the same AI agent access pattern, known as Cross App Access (XAA). The order of the announcements matters less than the fact that all three implemented the same combination of two technical specifications, suggesting that the industry has found a de facto standard for a problem that until now was solved with patches: how a company lets an agent access third-party applications and MCP servers on a user's behalf without resorting to shared, long-lived API keys.

On August 24, Okta took "Agent SSO" to general availability, integrating Cross App Access into its core identity product, the same one used —according to the company itself— by more than 20,000 customers. The feature is included at no extra cost in existing SSO plans, while a broader package, "Okta for AI Agents," is sold separately. Okta describes Agent SSO's scope deliberately narrowly: solving how agents using Cross App Access connect to enterprise applications and MCP servers. Its Integration Network already offers out-of-the-box support for Anthropic (Claude), Archestra.AI, Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, MintMCP, Notion, Slack and Supabase.

A week later, on August 31, Auth0 completed its own implementation. On July 27 it had already opened early access to the "resource application" side (the API that accepts credentials issued by another system); with the late-August release it also took the "requesting application" role —the one that asks for the credential on the user's behalf— out of beta. The system runs on Auth0 Token Vault and the ID-JAG protocol: on the requesting side it currently works over OIDC and Okta Workforce connections, and on the resource side it accepts both SAML and OIDC enterprise providers.

Descope closed out the week on September 1, announcing simultaneous support for ID-JAG token validation and issuance. Unlike the other two, its launch explicitly targets B2B software teams: it adds self-service XAA configuration to the same suite that already includes SSO, SCIM and just-in-time provisioning, so that an enterprise customer's administrator can choose their identity provider, set trusted issuers, register agents and map user attributes through a guided wizard. Rishi Bhargava, Descope co-founder, summed up in the announcement itself the pressure facing companies that operate MCP servers: every B2B company that publishes one is about to hear the same question from its enterprise customers about whether they can govern agent access with their own identity provider.

Beneath the three announcements lies a common two-layer architecture that solves two distinct problems: who the calling software is, and who allows it to reach where. The first layer identifies the client through a "Client ID Metadata Document" (CIMD). The MCP specification dated July 28, 2026 deprecated dynamic client registration (DCR) in favor of CIMD, keeping DCR only for backward compatibility. A DCR credential is tied to the authorization server that issued it and must be re-registered if that server changes; a CIMD-type client_id, by contrast, is a self-hosted HTTPS URL that any authorization server can resolve on demand, and that portability is the underlying reason for the replacement. In an enterprise-managed environment this layer becomes indispensable: the identity provider writes a fixed client_id into every credential, and the application server has to recognize that identifier before the first credential arrives, which rules out a client that self-registers on the fly.

August was, in practice, the providers' CIMD month: Okta launched agent registration via CIMD as a research release on August 5 —administrators register a URL, developers control authentication at that endpoint, and Okta authenticates agents at runtime without storing credentials—; Clerk published its own CIMD beta on August 6; and Auth0 had already incorporated CIMD registration into the general availability of "Auth for MCP" in May. On the client side, tools such as VS Code, MCPJam, ChatGPT and Claude Code already publish their own metadata documents.

The second layer is delegation, and that is where the enterprise's real control resides: the ID-JAG token. According to Auth0's own explanation, the identity provider acts as the policy enforcement point: it issues the credential only if the administrator's policy allows that requesting application to reach that resource application on that user's behalf, and it can trim the requested permissions along the way. The two layers meet in a single field: in Auth0's example, the client_id included inside the ID-JAG is precisely a CIMD identifier, though that is a feature of how that particular client was registered, not a requirement of the protocol itself. Final responsibility remains conservative: according to the ID-JAG draft, the resource's authorization server retains the authority to issue access tokens to its own protected resources, and decides under its own local policy whether to honor the credential, what permissions to grant and what token to hand over. The practical advantage for teams building the API, as Auth0 describes it, is that the API validates the resulting token exactly like any other: the API code does not change and never "finds out" that an XAA exchange took place.

The obvious argument against this reading is that all of this is Okta's protocol dressed up as an open standard. Okta led the design, owns the integration network where the connectors live, and enterprise-managed authentication for Anthropic's MCP connectors reached general availability on August 24 with Okta as the only supported identity provider, as had been the case since the June beta. Seen from a buyer's position, the pattern and Okta's catalog may look like the same object.

This week's launches qualify that reading. Descope's validation path lets an organization register a trusted issuer per tenant and accept credentials from Okta, Ping and other providers that meet the standard. Auth0's requesting side works both over Okta Workforce and over generic OIDC connections. And the official MCP SDKs themselves are adopting XAA natively as the "Enterprise-Managed Authorization" extension, which is precisely the sign that a pattern is ceasing to be a single product's exclusive feature.

It is worth reviewing those SDKs' repositories before promising anything to a customer, though, because coverage is uneven and not in the direction the original roadmap suggested. When Okta announced the SDK work in late 2025, it said support would begin with TypeScript and Java. TypeScript did indeed ship. So did Python and C#, the latter demonstrated on Okta's own developer blog this summer. The enterprise-managed authorization PR for the Java SDK, by contrast, was closed without merging and marked "wontfix." If an MCP server is written in Java, the native SDK path simply does not exist yet, and the exchange has to be implemented in-house.

The figures cited by the industry itself explain why this is not an architectural whim. According to Okta's own research, only 34% of organizations apply to AI agents the same security controls they apply to human workers. Descope, for its part, cites a 2026 Gravitee study according to which only 22% of teams treat agents as independent identities, with most still relying on shared API keys. The alternative to this pattern is not a better pattern: it is the API key still alive in a .env file six months after the person who generated it left the company.

The article, published on the WorkOS blog, also positions that company's own offering as the neutral piece of this ecosystem, built before the specification was formalized. WorkOS Connect has read URL-format client_ids, resolved the metadata and rendered the corresponding consent screen since November 30, 2025 —well before the July 28, 2026 MCP specification named CIMD as DCR's replacement—; the feature is off by default and is enabled in the Connect dashboard, under Settings. AuthKit, for its part, accepts ID-JAG credentials from enterprise identity providers in early access, handling JWKS signature verification, audience and claims validation, policy enforcement and the issuance of scope-limited tokens. And auth.md, the open agent registration protocol WorkOS says it created, was integrated into AuthKit as "Agent Registration" on August 4; its reference implementation is MIT-licensed and requires no WorkOS account either to publish or to read. None of this forces taking sides with a particular identity provider: it is what you get from building against the specification rather than against a single vendor's SDK. WorkOS in fact appears among the identity infrastructure and gateway partners mentioned in Okta's own Cross App Access partner announcement in June, and the same code works identically with a customer using Ping or Keycloak, because the trust relationship is a per-customer issuer configuration inside the product itself, not a vendor choice.

The practical conclusion the article puts forward is not which identity provider to choose, but whether your own authorization server already speaks this pattern. With three identity platforms implementing the same two specifications in the span of eight days, enterprise buyers now have a name for what they are going to ask for and a specific console from which to ask for it. The question any team operating a B2B application or an MCP server should settle this quarter is whether an enterprise administrator will be able, next quarter, to point an agent at their product and have it work without a per-user consent screen or a long-lived API key.

The first step, according to the article, is as simple as publishing four lines of RFC 8414-compliant metadata, because a client reads the grant_types_supported field to decide whether or not to offer the enterprise flow: a document with issuer, token_endpoint and, among the grant_types_supported, in addition to authorization_code and refresh_token, the urn:ietf:params:oauth:grant-type:jwt-bearer type. From there, what remains is resolving client_ids the company itself did not issue and maintaining, for each customer, a list of trusted issuers. None of this is a bet on a particular vendor's platform: it is, rather, the prerequisite for being able to integrate with any of them.