IdP federation with Cross App Access

What problem does federation solve?

An agent acting for a person may need several applications. Without this pattern, it asks the user to consent separately and stores a refresh token for each app. The existing guidance identifies limited administrator visibility as a problem with that arrangement.

Cross App Access routes the request through the identity provider the company already trusts. Keep that goal distinct from deciding whether every later action is acceptable.

This pattern concerns agents acting for signed-in people. Recommend starting with workflows where the represented user and target application are clear. Autonomous service agents have different identity requirements and should not be assumed to fit a user-based flow merely because they call applications.

How does the access flow work?

First, the user signs in to the agent through the company identity provider. The agent asks that provider for an ID-JAG naming the target application. The target application's authorization server accepts the ID-JAG and returns a short-lived access token for that user.

The ID-JAG is therefore part of obtaining downstream access, not a substitute for the entire application interaction. Recommend drawing the flow with separate agent, identity provider and target authorization server roles.

The target app's authorization server must participate in the documented flow. Do not assume that supporting sign-in through the same identity provider proves Cross App Access compatibility. The existing adoption guidance explicitly starts by checking which applications support Cross App Access.

What remains outside this pattern?

Cross App Access governs getting into an application. It does not check what the agent does once inside. A successful exchange should therefore not be presented as proof that a sensitive export, deletion or change received its own policy decision.

Add a governance layer where actions require separate policy or approval. That layer runs alongside the identity provider rather than replacing it. NewCore describes per-call allow, ask or deny decisions and named-person approval. Those are different requirements from federated application access.

Keep the agent identifiable as well as the represented person. The existing delegation guidance recommends carrying both identities and keeping the agent within the person's authority. Recommend reviewing that requirement separately from whether an access exchange completes successfully.

A hypothetical worked example

Suppose an employee asks an assistant to read a support case in one application and draft a response in another. Begin by checking Cross App Access support for both target applications.

The employee signs in to the assistant through the company identity provider. For the support application, the assistant requests an ID-JAG naming that target. Its authorization server accepts the grant and issues a short-lived access token for the employee.

Repeat the supported flow for the second application rather than assuming the first target's grant covers both. Recommend documenting each application's participation and the access the assistant actually needs.

Now suppose sending the drafted response requires human approval under company policy. Cross App Access alone does not supply that per-action check. Add the selected governance control and test the approval independently from the successful application access flow.

If one target lacks support, do not describe the entire workflow as migrated. Record the remaining token-based integration and its owner. Recommend planning its treatment explicitly rather than hiding the unsupported path inside a general federation success claim.

Which products document support?

Okta Agent SSO is built on Cross App Access. It became generally available on 24 August 2026 and is included in core Okta SSO. This makes it relevant when employees already use Okta and agents need SaaS access as those employees.

Descope added Cross App Access support on 1 September 2026. Its Agentic Identity Hub also names XAA/ID-JAG, MCP authorization, CIMD and PKCE. Descope documents short-lived scoped tokens and per-tool authorization with Deny policies. Evaluate those controls as distinct capabilities rather than interchangeable labels.

Aembit names XAA/ID-JAG among its standards and states that it does not replace the workforce identity provider. Its documented strengths include secretless exchange and a Blended Identity of agent and human. Require a demonstration of the intended integration rather than inferring every application connection from standards support.

Cross App Access became the MCP Enterprise-Managed Authorization extension, adopted by Anthropic, Microsoft and Okta. This establishes the standards connection in the reviewed sources. It does not establish that every application in a particular estate already supports the flow.

What should vendors demonstrate?

Require the identity provider and application vendors to explain their roles in the proposed exchange. Ask which target applications support it and how administrators review and revoke access. Recommend requesting evidence for the actual agent and applications, not just a general compatibility statement.

Separate access federation, credential handling and action approval in the requirements document. Okta's reviewed material lists Agent Gateway and human-in-the-loop as coming after general availability. Do not silently convert those roadmap statements into delivered per-action approval capabilities.

For Descope, the Free Forever tier includes the hub, while its governance suite is Enterprise only. That suite documents approval, purpose and an accountable owner. Recommend checking plan boundaries when a design combines Cross App Access with governance requirements.

How should adoption proceed?

Step one: list agents, represented users and target applications. Step two: check each application's support with the participating vendors. Step three: choose one supported workflow and document the exchange before replacing its existing access arrangement.

Step four: test the successful flow and administrative revocation. Step five: revoke the old stored tokens when moving the supported integration. Step six: test any separate action policy, then expand to additional supported applications.

Keep unsupported applications visible throughout the rollout. The main pitfalls are assuming universal app support, retaining old token paths and confusing centralized access with action approval. Recommend reviewing those three questions whenever the team adds another application or agent.

Questions buyers ask