Cross-App Access (XAA), also written Cross App Access, is an open, OAuth-based standard defined by the IETF that lets an AI agent or application reach another app on a user's behalf. The requesting app gets a short-lived, scoped token from the enterprise identity provider and calls the target app's API directly.
Key takeaways#
- XAA lets an agent get a short-lived, scoped token from the identity provider and call an app's API directly, with no long-lived per-app access credential to store.
- Its formal IETF name is the Identity Assertion JWT Authorization Grant. The short-lived JWT it issues is called an ID-JAG.
- The identity provider becomes the control point: it decides, by policy, what an agent can reach before any token is issued.
- Applied to the Model Context Protocol (MCP), XAA is the basis for enterprise-managed authorization (EMA).
How do XAA, ID-JAG, MCP, and EMA relate?#
These four terms travel together and are easy to confuse:
- XAA (Cross-App Access): the open OAuth standard for identity-provider-brokered access between apps and agents. Its formal IETF name is the Identity Assertion JWT Authorization Grant. (the standard)
- ID-JAG: the short-lived JWT that standard issues, carrying the user's identity and the scope of access. (the token)
- MCP (Model Context Protocol): the open protocol AI agents use to reach tools and data, and a major context where XAA applies. (the context)
- EMA (Enterprise-Managed Authorization): the MCP extension that applies XAA so an enterprise identity provider governs agent access. (the MCP outcome)
In short: XAA is the standard, ID-JAG is the token it issues, and EMA is what you get when XAA governs MCP connections.
How does Cross-App Access work?#
Cross-App Access works by making the identity provider the broker. The requesting app trades a user's sign-in for a short-lived, scoped token, then uses that token to call the target app. The flow has four roles: the requesting app (the agent or client), the enterprise identity provider, the resource app's authorization server, and the resource app itself.
- The user signs in to the requesting app through the enterprise identity provider, and the app receives an identity assertion (an OpenID Connect ID token or a SAML assertion).
- When the agent needs another app, the requesting app exchanges that assertion at the identity provider for an ID-JAG, a short-lived JWT scoped to a specific resource app, issued only after the provider evaluates organizational policy.
- The requesting app presents the ID-JAG to the resource app's authorization server, which validates it and returns an access token.
- The requesting app calls the resource app's API directly with that access token.
Because the identity provider evaluates policy at the exchange, an unauthorized request never receives an ID-JAG. Revoking access at the provider stops new tokens immediately, and any access token already issued expires on its short lifetime.
What is the IETF standard behind Cross-App Access?#
Cross-App Access is defined by an IETF OAuth specification formally titled the Identity Assertion JWT Authorization Grant. It profiles OAuth's identity-chaining work (the Identity and Authorization Chaining Across Domains draft), which builds on token exchange (RFC 8693) and the JWT profile for OAuth (RFC 7523). The specification is an active IETF OAuth Working Group Internet-Draft with an intended status of Standards Track. It is not yet a ratified RFC and is still subject to revision.
Why does Cross-App Access matter?#
AI agents and connected apps increasingly need to reach each other's data on a user's behalf. The common ways to do that don't scale safely. Static API keys sit in config files with no expiry and no owner. Per-app OAuth consent screens push the decision onto each user and scatter standing grants across the company. Neither gives security teams a consistent way to see or control what an agent can reach.
XAA moves that decision to the identity provider. Instead of the user wiring two apps together, the requesting app asks the provider, which evaluates policy, issues a scoped token when the request is allowed, and logs it. Access becomes short-lived instead of standing, scoped instead of blanket, and governed from the system the enterprise already trusts.
Is Cross-App Access secure?#
Yes, by design. XAA replaces long-lived, standing credentials with short-lived, scoped tokens that the identity provider issues only after it checks policy, so an agent gets the narrow access it needs and nothing more. Every request is brokered and logged at the provider, and revoking access there stops new tokens immediately. The trade-off to plan for: an access token already issued stays valid until it expires, so token lifetimes should be kept short.
Cross-App Access vs. API keys and per-app OAuth#
| Static API keys / per-app OAuth | Cross-App Access (XAA) | |
|---|---|---|
| Credential | Long-lived, stored per app | Short-lived, scoped token per request |
| Who decides | The app or the individual user | The enterprise identity provider, by policy |
| Revocation | Per app, often manual | At the identity provider; new access stops immediately |
| Offboarding | Keys and grants linger | Central; new access ends with the identity |
| Audit | Scattered across apps | One centralized record |
How does Cross-App Access relate to MCP and enterprise-managed authorization?#
Cross-App Access is a general standard, not tied to one protocol. Applied to the Model Context Protocol, it becomes the basis for enterprise-managed authorization (EMA), the MCP extension that lets an enterprise govern how AI agents reach MCP servers. XAA is the access standard; EMA is the MCP-specific application of it. Every EMA deployment uses XAA, but XAA is also used outside MCP.
How do enterprises use Cross-App Access?#
An identity provider issues the scoped tokens, and the resource apps accept them. For the apps that support the standard, agents get direct, scoped access. For SaaS apps, on-premises systems, and legacy tools that don't support it yet, a gateway governs those connections under the same policy, so coverage isn't limited to the apps that have already adopted it. Early implementations began appearing in 2026, with AI tools such as Claude among the first to support it.
Govern Cross-App Access with C1#
C1 is the control plane for agent access. C1 acts as an enterprise identity provider and token issuer for Cross-App Access, and governs everything the standard doesn't reach yet through its AI Access Management (AIAM) gateway, all from one console.
- One control plane for every way an agent reaches an app, the standard and everything else.
- One policy and one audit trail across the direct path and the gateway.
- Short-lived, scoped tokens on the direct path, with no standing per-app secrets to manage.
- Govern agents like people: the same access reviews, certifications, and approvals.
Ready to govern agent access? Book a demo to see C1 in action.
