---
title: "Cross App Access Shows How the Layered Play Ships"
date: "2026-08-10T12:00:00-07:00"
lastmod: "2026-08-10T12:00:00-07:00"
description: "MCP's stable Enterprise-Managed Authorization extension, a live Claude and Okta beta, and more than twenty-five early adopters show how an identity-layer foothold can arrive with distribution attached. Cross App Access governs a durable connection and projects user authority to a named OAuth client. It does not yet bind a portable Agent deployment or record the approved work."
summary: "Cross App Access is not twenty-five generally available integrations. It is three different things at three different stages: a stable MCP authorization extension, a live Claude and Okta beta, and a partner graph whose broader product rollout is still under way. That distinction makes the strategic result clearer. The launch coalition moves protocol coordination from each buyer to the vendors assembling the loop, giving the layered identity play an adoption wedge. ID-JAG carries both the enterprise user and a required OAuth client identifier, while the resource authorization server retains the final decision. What it does not standardize is the binding from that client to a logical Agent, approved deployment, or runtime instance, nor a record of the task that justifies access. The credential-projection foothold shipped. The Agent and approved-work records remain open."
slug: "cross-app-access-is-the-layered-play-shipping"
tags:
  - "Agentic Identity"
  - "OAuth"
  - "MCP"
  - "Standards"
  - "Interoperability"
---


Cross App Access is shipping, but that sentence compresses three different milestones into one verb.

| Layer | What is established | What remains unproven |
| --- | --- | --- |
| **Protocol** | MCP declared its [Enterprise-Managed Authorization extension](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/) stable on June 18, 2026 | The underlying [Identity Assertion JWT Authorization Grant](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) remains an IETF Internet-Draft, not a finished RFC |
| **Working deployment** | Anthropic made [enterprise-managed authorization](https://claude.com/blog/enterprise-managed-auth) available in beta for Claude Team and Enterprise, starting with Okta and seven MCP providers. The same managed connector access applies across Claude chat, Claude Code, and Cowork | The feature is still a beta, Okta is the only supported IdP at launch, and Slack is listed as coming soon |
| **Ecosystem rollout** | Okta announced [more than twenty-five early adopters](https://www.okta.com/newsroom/press-releases/okta-announces-cross-app-access-partners/) across requesting apps, resource apps, gateways, and identity infrastructure on June 23 | "Early adopter" does not mean every integration is generally available. Auth0 opened early access for resource applications at the end of July, as planned, while Okta's commitment that Workforce customers could reach these apps through the Integration Network starting in August has no independent confirmation yet that it is live. A commitment met on one side and unconfirmed on the other is still not proof the whole roster is generally available |

That is enough to make the strategic result real without turning a launch roster into a deployment count. A complete loop is running with joint customers. The MCP extension is stable. The larger commercial graph is committed and still rolling out.

The wire underneath is ID-JAG, from the OAuth identity-chaining family. The flow has four important steps. First, the user signs in to the requesting app through the enterprise identity provider. Second, the requesting app uses that identity assertion to ask the IdP for an ID-JAG addressed to the resource's authorization server. Third, the app exchanges the ID-JAG for a resource access token. Finally, the resource authorization server applies its own policy before issuing that token.

Two details matter for the analysis that follows. The ID-JAG contains a required user subject and a required OAuth client identifier. It is not merely a user token passed through an agent. It can also carry scopes, resource indicators, and structured authorization details. And the durable product object is the IdP-managed connection between a requesting app and a resource app, not the short-lived assertion or access token.

This note reads the rollout through [the control-points series](/series/agent-control-points/), because Cross App Access shows both how the layered play can reach the market and where that play still stops.

## The Layered Play, Arriving With Distribution

[The identity-binding essay](/notes/the-runtime-mints-the-identity/) laid out three plays for the layer above runtimes and gave the layered play a burden. It has to arrive as a property of the paved road, because if enterprise binding is a per-team integration project, friction alone decides the market. Cross App Access accepts the distribution part of that burden. It puts the enterprise IdP into the authorization path between heterogeneous requesting and resource apps, and lets managed connections inherit the assignment, group, policy, revocation, and authorization-audit surfaces that enterprises already operate.

It does not deliver the whole binding layer the essay defined. That layer also has to accept runtime evidence and bind a running instance to durable enterprise records for a logical Agent and an approved deployment. Cross App Access begins farther down the stack, at credential projection. Its achievement is to make that foothold distributable through the existing SSO estate and an open MCP extension.

The historical rhyme is hard to miss and worth saying plainly. Okta built its first business by layering on Active Directory and federating out to applications the enterprise did not own. Cross App Access is the same shape one substrate later, the neutral hub layering on MCP, the rails that already won tool integration, and federating agent connections across applications the enterprise does not own. The essay's history section argued the join wins the closed round and the layer wins the heterogeneous one. The layer just placed its bet.

The launch does not settle the contest between bundled and layered identity. The Claude beta starts with one IdP, Okta, while Microsoft appears in the wider adopter list through VS Code and can still pursue its own identity plane. What the launch proves is narrower and more important. The MCP authorization rail can support an identity layer that is neither the harness nor the resource provider.

## The Third Way to Shrink a Coordination Radius

[The MCP Lesson](/notes/the-mcp-lesson/) argued that a seam's fate turns on the coordination radius of its first useful deployment, and that MCP won by making the first complete adoption unit one-developer-sized. Cross App Access had no such option. Its loop is irreducibly multi-party. An IdP, a requesting app, and a resource authorization server all have to speak the protocol before the flow produces value, which is the shape that usually dies waiting for an ecosystem.

The rollout shows the escape. When the loop cannot be made small, pre-assemble it. Okta and its partners implemented the sides before broad product availability, so a joint customer configures a connection instead of negotiating a three-way integration. The administrator still has prerequisites to satisfy, apps to configure, a managed connection to create, and policy to assign, so this is not literally one switch. But the buyer no longer has to persuade three vendors to build the same flow.

Okta does not pay the coordination cost alone. It moves that cost from every buyer into the product roadmaps of the IdP, client, resource, and infrastructure vendors before rollout. The standard keeps the seam open. The launch coalition supplies the adoption wedge. The result is open on the wire and commercially centered on Okta at launch, a distinction that will matter when additional IdPs try to enter the same path.

The governance sequence repeated too, and by now it should look familiar: an extension proposal and running code, a live customer beta, then a stable MCP extension and broader partner commitment. Utility and specification work reinforced each other. That is the adoption order the companion essay argues can arrive before a distributed incumbent closes the seam.

## The Checkpoints Still Hold

Reading a launch through a friendly lens obligates the unfriendly checks, and the series supplies them. The binding essay's incident asks three questions of any agent action, whose agent, which approved deployment, and which approved undertaking. Cross App Access answers a different pair, which employee and which OAuth client, while the original three stay open.

**It hides the dance from the agent, which is the provider seam's case in miniature.** The four-step ID-JAG flow is exactly the mechanism [the provider-seam essay](/notes/kerberos-won-because-nobody-had-to-implement-it/) argues agent logic should never carry: assertion in, grant out, token exchanged, all before a tool call. In the shipping loop that machinery lives in the requesting app and the gateway products rather than in the agent, and the seven MCP providers in the beta are one seam being pre-assembled. What remains unstandardized is the seam's general form, an interface any harness can call without knowing which of these flows produced the credential.

**It identifies the user and the OAuth client, not an Agent deployment.** Run Cross App Access through the binding essay's five jobs and it lands on credential projection, done well, while leaving the resource decision local. The ID-JAG's required `sub` identifies the enterprise user and its required `client_id` identifies the OAuth client that will act for that user. A managed connection also names the requesting and resource applications. Those are real improvements over an opaque bearer token.

But an OAuth client might be Claude, VS Code, a gateway, or a custom agent application. The identifier does not by itself name a portable logical Agent, distinguish its approved deployment, identify the runtime instance now executing, or bind runtime evidence to that instance. ID-JAG permits an actor claim, but the draft explicitly leaves actor-token processing to future profiles. Cross App Access therefore supplies useful app inventory without completing the Agent inventory described by the binding essay, a scope boundary rather than a protocol defect.

**It is the grant machinery, materially improved, not the task record.** [The system-of-record essay](/notes/agent-authority-has-no-system-of-record/) named the identity platform's consent and grant machinery as one possible home for approved work. Cross App Access is that machinery becoming materially better. It replaces scattered user consent with an administrator-managed connection, can narrow issuance by group, role, scope, resource, and structured authorization details, and supports short-lived credentials and centralized revocation.

The distinction between token and entitlement matters. XAA can remove long-lived static credentials while leaving a durable policy entitlement. As long as the managed connection and assignment remain active, the client can obtain fresh task-agnostic access for the user. Nothing in XAA or the MCP extension defines an undertaking, gives it an owner and lifecycle, or requires each derived credential to cite it. Structured authorization details could carry richer bounds in a future profile. They do not create shared task semantics by themselves. The standing access is smaller, more visible, and easier to revoke. It is still not approved work.

**The resource keeps the final word.** The resource authorization server validates the ID-JAG, applies local policy, and decides what access token to issue. That is consistent with the series' map and worth preserving as the ecosystem hardens. It also marks the audit boundary: XAA standardizes the authorization path and makes its decisions observable, but it does not define an end-to-end log schema for every tool call or prove which approved task an action served.

None of this diminishes the rollout. It locates it. One control point's contest has produced an ecosystem-scale move, and the foothold that arrived governs which requesting application may approach which resource, for which employee, under enterprise policy. Nothing in the flow yet proves which approved Agent deployment is at the door, why it is there, or when that reason expires.

> Cross App Access proves that a layered seam can ship with distribution attached. The connection is governed, the user and OAuth client are named, and the resource keeps the final word. The Agent deployment is still unbound and the approved work is still unrecorded. The foothold shipped. Two records remain open.