Cross App Access and MCP governance for AI app integrations

At a glance

What this is: Cross App Access puts enterprise IdPs back into AI app-to-tool delegation, making MCP connections centrally governable instead of hidden inside downstream OAuth grants.

Why it matters: It matters because IAM, NHI, and agentic AI programmes now need one control plane for app-to-app access, revocation, and auditability before integrations sprawl beyond review.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS's analysis of Cross App Access for MCP governance

Context

Cross App Access is an answer to a familiar IAM problem in a new setting: when an AI app connects to a tool through MCP, the enterprise often loses sight of who authorised what, for which scopes, and for how long. The result is delegated access that exists operationally but not governance-wise, which is exactly where shadow IT starts.

For identity teams, the issue is not whether OAuth works. It is whether app-to-app delegation can be made visible, policy-backed, and revocable from the enterprise IdP instead of being buried in each downstream integration. That matters across NHI, autonomous, and human identity programmes because the control gap is the delegation path itself, not the user login.

The practical shift is toward enterprise-managed authorization for AI app connections. The source article frames Cross App Access as an IdP-in-the-loop model for MCP, which makes the identity plane the decision point for cross-app access rather than leaving that decision inside every tool.

Key questions

Q: How should security teams govern AI app connections in MCP environments?

A: Security teams should treat each AI app connection as a governed identity relationship, not a private integration inside the downstream tool. That means the IdP should approve the connection, scopes should be pre-authorised, and revocation should happen centrally. Without that model, AI app access becomes distributed shadow IT with no reliable audit trail.

Q: Why do app-to-app OAuth grants create governance risk for AI integrations?

A: App-to-app OAuth grants create governance risk because the enterprise can lose sight of who approved the delegation, what the app can do, and how to revoke it. When the IdP is outside the flow, access can persist long after the original business need changes, especially in MCP environments with many connected tools.

Q: What breaks when AI app access is managed only inside downstream tools?

A: What breaks is visibility, consistency, and revocation. Each tool may expose a different approval path, different logs, and different token lifetimes, so the enterprise cannot answer the same governance question in one place. That makes access reviews incomplete and leaves hidden delegation paths in production.

Q: Who should own revocation decisions for AI app-to-tool delegation?

A: The identity team should own revocation decisions because the IdP is the only place with a complete view of user identity, approved clients, and downstream trust relationships. If revocation lives only in the application, enterprises will miss connected grants that still exist elsewhere. Central ownership is the only scalable control.

Technical breakdown

Identity assertion authorization grant in app-to-app OAuth

Identity Assertion JWT Authorization Grant, or ID-JAG, is the mechanism that lets an enterprise IdP issue a short-lived signed assertion for a specific client, user, and downstream app. The assertion is audience-bound, so it can only be redeemed at the intended MCP server, and it is not itself an access token. The downstream server validates the signature, checks the claims, and then mints a normal token. That gives the enterprise a policy checkpoint before delegation becomes usable. It is a cleaner trust handoff than user-by-user consent scattered across tools.

Practical implication: treat the IdP as the authorisation authority for AI app connections, not just the place where users authenticate.

Why MCP delegation becomes an identity governance problem

MCP changes the scale of app-to-app access because an AI client can connect to multiple tools in one working session. That multiplies delegation paths, scopes, and revocation events faster than human admins can inspect them manually. Without an IdP-mediated grant, the enterprise cannot easily answer which AI apps can act in which tools, under whose identity, or with what effective permissions. In practice, this is not a protocol detail. It is a governance failure mode where delegated reach exceeds the organisation's ability to certify it.

Practical implication: inventory MCP connections as governed identity relationships, not as isolated application integrations.

Short-lived assertions versus standing access tokens

XAA relies on short-lived assertions that can be exchanged for short-lived MCP access tokens, which limits the accumulation of durable downstream privilege. That matters because many AI integrations still default to API keys or refresh tokens when they need non-interactive access. Those durable credentials outlive the business approval that created them, and they are harder to revoke consistently. Short-lived, IdP-approved assertions move the control boundary back to the enterprise and reduce the need for long-lived secrets in the integration layer.

Practical implication: design MCP authorization flows to expire quickly and to re-enter policy evaluation on renewal.

Threat narrative

Attacker objective: The objective is to preserve hidden cross-app access long enough to extract data, trigger actions, or maintain integration reach without enterprise review.

1. Entry begins when a user connects an AI app to a downstream tool through direct OAuth and the enterprise IdP cannot see the delegation relationship.
2. Credential access or abuse follows when the AI app receives tokens or durable credentials that let it act inside the tool without centralized policy enforcement.
3. Impact occurs when revoked, unscoped, or forgotten app-to-app grants continue to provide access across multiple MCP-connected systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Invisible delegation is the governance failure Cross App Access is trying to close. When the IdP only sees the user login and not the app-to-app relationship, the enterprise loses its normal control plane. That means no pre-delegation policy gate, no normalized audit trail, and no single revocation lever. The implication for practitioners is that AI app integrations must be governed as first-class identity relationships, not as invisible downstream conveniences.

Cross-app AI access exposes an identity blast radius problem, not just a consent problem. Once one AI client can connect to multiple MCP servers, scope drift and hidden reuse become the real risk. A single delegated connection can fan out across project tools, ticketing systems, and data stores faster than humans can review. Practitioners need to reframe MCP governance around blast radius containment, because the question is how far one approved connection can reach before someone notices.

Enterprise-managed authorization becomes the default expectation for AI app integrations. The market is moving toward IdP-mediated approvals because security teams want a central place to enforce allowlists, step-up checks, and revocation. That does not eliminate risk, but it makes delegation observable and policy-backed. For IAM and NHI programmes, the practical conclusion is that integration governance now belongs in the identity layer, not inside each app team.

Short-lived delegation is now part of enterprise identity hygiene for AI systems. Durable credentials make AI integrations look convenient but they also create persistence that survives context changes. XAA shifts the approval model toward re-issuable, policy-checked access, which aligns with zero standing privilege thinking even when the subject is an AI app. Practitioners should expect enterprise buyers to ask how cross-app access is authorized, not just whether it works.

Cross App Access sharpens a named concept: the delegation visibility gap. This is the space between a user authenticating and the enterprise actually understanding which AI app can act where. That gap is where shadow IT, unreviewed scopes, and weak revocation accumulate. The implication is straightforward: if the delegation path is not visible at the IdP, it is not governable at enterprise scale.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to the State of MCP Server Security 2025.
• That exposure pattern helps explain why hidden app-to-tool delegation becomes so hard to govern once credentials are embedded in configs rather than mediated by the IdP.
• For a broader control view, see Ultimate Guide to NHIs , Key Challenges and Risks for how unmanaged secrets and overprivilege compound access sprawl.

What this signals

Delegation visibility is becoming a baseline identity requirement for AI app programmes. If the IdP cannot see cross-app grants, security teams will continue to inherit opaque access paths that are hard to review, hard to revoke, and easy to duplicate. This is where governance moves from login control to delegation control, which is a materially different programme boundary.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, according to the State of MCP Server Security 2025, the operational lesson is that integration sprawl is already producing credential debt. Teams that keep relying on durable secrets for AI app connectivity will find that their review cycles lag behind their deployment cycles.

Identity blast radius: the practical risk is not just that one AI app connects to one tool, but that one delegated path can expand across a whole working stack. That means practitioners should prepare for policy design that limits app-to-app reach at the IdP, not just in the target application.

For practitioners

• Map AI app connections as identity relationships Inventory every MCP client and server pair, then record who approved the relationship, what scopes were granted, and where revocation is enforced. Use the IdP as the source of truth for app-to-app delegation.
• Enforce allowlists before token issuance Require policy checks in the enterprise IdP before any identity assertion is minted, including client-to-server allowlists, group membership checks, and step-up authentication for sensitive tools.
• Replace durable credentials with short-lived assertions Eliminate long-lived API keys and unmanaged refresh tokens from MCP integrations where possible, and prefer short-lived, re-issuable assertions that expire under policy.
• Tie revocation to the identity plane Make the IdP the place where downstream AI app access is killed, audited, and re-authorised, so revocation does not depend on hunting through each tool one by one.

Key takeaways

• Cross App Access turns AI app delegation into a governed identity problem instead of a hidden OAuth side effect.
• The main exposure is invisible delegation, where access exists outside the enterprise control plane and cannot be centrally reviewed.
• Enterprises should move AI app authorization into the IdP, because short-lived assertions and central revocation are the only scalable controls here.

Key terms

• Identity Assertion Authorization Grant: An OAuth extension that lets an identity provider issue a signed, short-lived assertion saying a specific client may act for a specific user at a specific downstream app. It shifts approval from the target tool to the enterprise identity plane, which is what makes cross-app delegation governable at scale.
• Cross App Access: An ecosystem name for IdP-mediated app-to-app authorization in enterprise environments. It allows an identity provider to approve or deny AI app connections centrally, reducing hidden delegation and making downstream access revocable from one place instead of inside every connected tool.
• Delegation Visibility Gap: The space between a user authenticating and the enterprise being able to see, approve, and revoke the downstream app-to-app relationship. In AI and MCP environments, this gap creates shadow IT, weak audit trails, and access that survives longer than its business justification.
• Identity Blast Radius: The total reach of a delegated identity relationship across tools, data sources, and actions once access is granted. For AI apps, the blast radius can expand quickly through connected integrations, so governance has to limit scope before the first token is issued.

Deepen your knowledge

Cross App Access and AI app delegation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance around MCP integrations or other cross-app workflows, it is worth exploring.

This post draws on content published by WorkOS: Cross App Access (XAA) and MCP enterprise authorization. Read the original.