Notifications
Clear all
Topic starter
07/06/2026 8:38 pm
TL;DR: Cross App Access inserts the enterprise IdP into app-to-app OAuth so AI apps and MCP servers can be governed centrally, with short-lived identity assertions, policy gates, and auditable delegation, according to WorkOS. That shifts AI app access from invisible shadow IT into a controllable identity plane, but it also assumes IdP mediation can keep pace with dynamic integration growth.
NHIMG editorial — based on content published by WorkOS: Cross App Access (XAA) and MCP enterprise authorization
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.
Questions worth separating out
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.
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.
Q: What breaks when AI app access is managed only inside downstream tools?
A: What breaks is visibility, consistency, and revocation.
Practitioner guidance
- 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.
- 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.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step identity assertion and token exchange flow across the IdP, MCP client, and MCP server
- Implementation notes for confidential clients, audience binding, and JWKS validation
- How WorkOS positions AuthKit, Connect, RBAC, and Audit Logs within the XAA flow
- The spec-level distinctions between ID-JAG and the XAA ecosystem label
👉 Read WorkOS's analysis of Cross App Access for MCP governance →
Cross App Access for MCP apps: what changes for IAM teams?
Explore further
08/06/2026 8:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cross App Access and MCP governance for AI app integrations
