Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
Hello Descopers! We're delighted to share that Cross-App Access (XAA) support is generally available as a part of the Agentic Identity Hub. XAA is a standards-based way of letting every enterprise customer manage and control AI agent access through the identity provider they already trust.
Descope is among the first identity providers to support both:
ID-JAG token validation, which enables SSO-like login for any AI agent accessing your MCP server.
ID-JAG token issuance, which enables SSO-like login for your AI agents accessing any MCP server.
You can read the Enterprise-Managed Authorization documentation to see how issuance and validation are configured in Descope, or try the flow yourself in the Cross-App Access developer playground. To learn more about the Why, What, and How of XAA support, keep on reading.
The identity gap between AI agents and enterprise buyers
AI agents are becoming the primary consumers of enterprise APIs, and B2B companies are building MCP servers so those agents can reach intended services and data. The identity patterns those servers inherit, though, were designed for humans and static services rather than for autonomous and “unpredictable” software like AI agents.
What API keys and consent screens leave behind
Most MCP servers in production today rely on one of two mechanisms, with both of them running into limits at enterprise scale.
API keys are the default path. 2026 research from Gravitee found that only 22% of teams treat agents as independent identities, with most relying on shared API keys.However, API keys are often:
Long-lived, since they do not expire unless somebody manually revokes them.
Over-scoped, granting broad access rather than permissions for the task at hand.
Decentralized, since they are spread across config files, environment variables, and local machines.
OAuth consent flows improve on this with expiring tokens and explicit user permission, but they introduce a different set of problems once an organization connects more than a handful of applications.
Users click through repeated consent prompts.
IT has no single view of which applications can reach which data.
Access management stays fragmented across each resource application.
Security teams cannot approve safe integrations or block risky ones ahead of time, because every authorization decision happens at the level of an individual user.
Neither mechanism suits an enterprise agent. What does suit enterprise agents is using their existing identity providers.
When a B2B company exposes an MCP server, its enterprise customers now ask whether their own security team can control which agents reach the MCP server, using the identity provider they already run.
Answering this request per customer means building token exchange, per-tenant issuer trust, claim mapping, and audience validation, then maintaining all of it as the MCP authorization specification changes.
Cross-App Access 101
Cross-App Access is an open protocol that standardizes how an AI agent gets access to another application's APIs or MCP server. It is built on the Identity Assertion JWT Authorization Grant (ID-JAG) and was adopted as the Enterprise-Managed Authorization extension to the Model Context Protocol.
Rather than a static API key or a consent screen, the identity provider that both applications already trust mints a short-lived, scoped assertion for each request. An agent signed in to one application reaches another application's API or MCP server with no second login.
How it works
Three parties take part in an XAA flow: the requesting app (the agent or MCP client), the enterprise IdP, and the resource app that owns the API or MCP server.
The user authenticates with the IdP through SSO and receives an ID token.
The requesting app exchanges that ID token for an ID-JAG at the IdP's token endpoint.
The IdP validates the request against company policy, checking whether the requesting app is allowed to reach the resource app with the scopes it asked for.
If the request is approved, the IdP issues a signed ID-JAG assertion back to the requesting app.
The requesting app presents the assertion to the resource app's authorization server.
The resource app validates the signature against the IdP's public keys and issues a short-lived access token.
The requesting app calls the API with that token until it expires.
Also Read: What Is Cross-App Access (XAA) and How It Works
Cross-App Access in the Agentic Identity Hub
Descope supports both sides of the XAA exchange as an issuer and validator of ID-JAG tokens.
Validating ID-JAG tokens
Validation is for companies that sell an MCP server to enterprises. You can:
Register a trusted issuer for each tenant so an assertion minted for one customer cannot be used against another.
Accept assertions from Okta, Ping, and other standards-compliant providers.
Apply per-organization scope policies based on user roles, tenant membership, and claims carried over from the customer's identity provider, so two customers on the same MCP server can receive different levels of agent access.
Your MCP server does not need to understand ID-JAG. Descope validates the incoming assertion, matches its subject to the user provisioned through that customer's SSO connection, and issues a standard access token that your server validates the way it validates any other request.
Issuing ID-JAG tokens
Issuance is for organizations that run their own AI agents and want those agents to reach MCP servers and APIs. You can:
Register the downstream target as an MCP Server or API Resource and mirror the scopes it expects.
Point the MCP client at Descope as its identity provider.
Write a token exchange policy that governs which agents and users can obtain an assertion for that resource, and with which scopes.
Because the exchange happens per request, policies are evaluated in the request path rather than baked into a long-lived credential.
The difference in user experience with and without XAA is stark. Once XAA is enabled, your agent can automatically connect to all authorized MCP servers and APIs without repeated consent prompts or re-authentication.
Self-service XAA setup for tenant admins
Cross-App Access now also sits in the Descope SSO Setup Suite alongside SSO, SCIM, and JIT provisioning. Your customers' IT admins can choose their identity provider, establish trusted issuers, register their AI agents, and map user attributes through a guided flow… all without a support ticket or manual back-and-forth with your team.
Cross-App Access use cases
Enterprise-ready MCP servers
Consider a B2B analytics company, Arclight Analytics, that has shipped a customer-facing MCP server so their users can query dashboards and pull reports from Claude or ChatGPT.
Arclight uses the Agentic Identity Hub for the full auth layer on that server. Even without XAA, they could:
Securely connect the MCP server to agents with OAuth 2.1 and PKCE.
Support spec-compliant client registration (CIMD and DCR) with risk assessment flows applied at registration time.
Expose per-agent and per-tool scopes, so an agent that reads dashboards cannot export the underlying dataset.
With XAA, each enterprise customer can connect their own IdP as a trusted issuer and their security team can decide which agents reach Arclight's data.
When a prospect's security team asks whether agent access can be managed from their Okta tenant, Arclight's answer is a configuration step their customer completes themselves rather than an engineering commitment on the deal timeline.
Managing internal AI agents
Now consider Sundial Logistics, a fictional shipping company running internal agents that pull ticket history, check inventory systems, and file updates across several third-party MCP servers.
Before XAA with Descope, each agent held a static API key per service. Sundial had no way to tell which agent used which key, no way to narrow an agent's access without re-issuing credentials, and no way to revoke access without hunting down every key.
With ID-JAG issuance, Descope becomes the identity provider for those agents:
Each downstream MCP server and API is registered as a Resource with the scopes it expects.
A token exchange policy decides which agents, users, and tenants can reach each resource, which is evaluated on every request.
Agents receive a short-lived, scoped assertion rather than a credential that works everywhere indefinitely.
Every exchange is logged against the agent identity, the delegating user, and the resource, and streams to Sundial's SIEM alongside the rest of their audit data.
Toward agent access without the second login
Enterprise buyers already know what good access management looks like for their employees, and they are asking for the same thing for the agents acting on their behalf. Cross-App Access gives the industry a standards-based way to deliver it, and supporting both issuance and validation means a Descope customer can be on either side of that exchange, or both.
Sign up for Descope to start using Cross-App Access today, or book a demo with our auth experts to learn more.
