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.
At a glance
What this is: This is a governance analysis of how Cross App Access brings MCP app connections into the enterprise IdP so AI app delegation becomes visible, policy-driven, and revocable.
Why it matters: IAM and IGA teams need this because AI integrations are increasingly acting like shadow app-to-app grants, and the control point shifts to identity policy rather than downstream tokens.
Context
MCP app delegation is no longer a narrow integration concern. Once AI clients can connect to multiple tools through OAuth, the core issue becomes who can authorise that connection, what scope is granted, and how quickly the enterprise can revoke it when the relationship changes.
Cross App Access shifts that decision into the enterprise IdP by inserting a policy gate before app-to-app access is minted. For identity programmes, the question is not whether AI apps should connect, but whether delegation can be governed with the same lifecycle discipline used for other high-risk access paths.
The primary identity problem is invisible delegation across app boundaries. Without central mediation, the enterprise sees user sign-in but loses the authorisation trail for AI clients acting on the user’s behalf.
Key questions
Q: What breaks when AI app access is not mediated by the enterprise IdP?
A: What breaks is the enterprise’s ability to see, approve, and revoke app-to-app delegation as a governed identity event. Without IdP mediation, AI clients can accumulate downstream access through scattered OAuth grants that security teams cannot reliably inventory or remove from one place.
Q: Why does app-to-app OAuth create higher governance risk for MCP integrations?
A: Because the token path can grant a client user-level authority inside multiple business tools while the enterprise only sees a sign-in, not the delegation decision. That separation makes scope creep, weak approvals, and delayed revocation much more likely in fast-growing AI integration estates.
Q: How can security teams tell whether Cross App Access is actually improving control?
A: Look for a single policy and audit trail in the IdP that lists approved client-server pairs, granted scopes, expiry times, and revocation actions. If those decisions still live in downstream apps, the organisation has visibility but not governance.
Q: What should IAM teams do when an AI app integration needs to be revoked?
A: Revoke the delegation at the enterprise identity provider first, then confirm downstream apps no longer accept the assertion path. If teams only remove local app permissions, the same client may continue to obtain access through another grant path.
Technical breakdown
How Cross App Access changes OAuth delegation for MCP
Traditional OAuth delegation is user-centric: an app receives access because the user consented or the app already held its own credentials. Cross App Access inserts the enterprise IdP into that exchange so the IdP can decide whether a client is allowed to act for a user at a downstream MCP server. The key change is that the authorisation relationship becomes enterprise-managed rather than inferred from a downstream token grant. That matters because MCP clients can fan out across many tools, which turns isolated consent events into a governance surface. The IdP can now apply allowlists, scope restrictions, and step-up checks before any access token exists.
Practical implication: treat app-to-app OAuth as a governed delegation path, not a user convenience feature.
Identity Assertion JWT Authorization Grant and short-lived assertions
The underlying mechanism is the Identity Assertion JWT Authorization Grant, or ID-JAG. The IdP issues a signed, audience-bound JWT that says a particular client may act for a particular user at a particular resource with specific scopes and a short expiry. That JWT is not the final access token. The downstream MCP server validates the assertion against the IdP’s signing keys and then mints a normal access token. This structure matters because it preserves enterprise policy control while avoiding long-lived standing privilege. It also makes the trust boundary explicit: the assertion is the enterprise-approved permission slip, and the resource server remains responsible for validating it correctly.
Practical implication: validate audience, expiry, and claims on every assertion redemption path.
Why centralized revocation becomes the real control point
The governance value of Cross App Access is not just visibility. It creates a single revocation lever for app-to-app access that otherwise fragments across downstream tools. In distributed AI integrations, the enterprise often cannot answer which app has which scopes, or where to revoke access without chasing every SaaS connection separately. By moving approval and token issuance back through the IdP, XAA collapses that sprawl into a single policy domain. That is the architectural difference between monitoring integration growth and actually governing it. The downstream token still exists, but its lifetime and legitimacy are now anchored in the enterprise identity plane rather than individual user choices.
Practical implication: design revocation workflows around the IdP, not around each downstream application.
Threat narrative
Attacker objective: The objective is to gain durable, opaque app-to-app access that operates with user authority while evading centralized enterprise governance.
- Entry occurs when a user connects an AI client to a downstream tool through ordinary OAuth and the enterprise IdP is bypassed in the delegation step.
- Credential abuse follows when the downstream app mints tokens that let the AI client act with user-level scopes, while the enterprise cannot see the grant centrally.
- Impact is governance blindness: the organisation loses a single revocation path, cannot inventory which AI apps can reach which tools, and must hunt through each downstream integration to contain access.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Invisible delegation is now the governance failure mode, not consent fatigue. Cross-app AI access turns scattered user authorisations into an identity control problem because the enterprise can no longer rely on downstream app logs to reconstruct who approved what. The useful boundary is not the user click, but the enterprise decision to allow one client to act in another app’s trust domain. Practitioners should treat cross-app grants as governed identity events, not incidental UX friction.
Cross App Access is a policy plane for delegated AI access, not an AI feature. The important shift is that the IdP becomes the decision point for app-to-app authorisation, which aligns MCP with existing identity governance models. That matters because the same organisational controls used for SaaS access review, conditional access, and entitlement approval can now apply to AI clients. The implication is that identity teams, not just app owners, become accountable for integration approval logic.
Short-lived assertions reduce the blast radius, but only if the enterprise owns the trust chain. XAA narrows exposure by replacing durable downstream grants with time-bound identity assertions, yet the model still depends on correct assertion validation and consistent IdP policy. That means the security outcome is determined less by the token format and more by whether the enterprise has operationalised the trust relationship end to end. Practitioners should focus on governable delegation paths, not just shorter token lifetimes.
Cross App Access creates the first credible identity trail for AI app sprawl. The enterprise has long struggled to inventory which AI clients can reach which business systems, and that gap becomes more acute as MCP adoption grows. Central mediation gives security teams a place to see, approve, and revoke those relationships in one control plane. The implication is straightforward: AI integration governance is becoming an IGA problem, not an isolated application problem.
Ephemeral delegation debt: Cross-app AI access still accumulates risk whenever organisations let integration paths expand faster than policy, because each approved client-server pair becomes part of the identity estate. That is a governance burden, not a protocol flaw. Practitioners should expect their review processes to track app-to-app relationships with the same discipline used for sensitive human and machine access.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Cross-app delegation is becoming part of the identity estate. Once AI clients can act across multiple SaaS tools, the real control problem is not authentication but governance of the relationship between client, user, and downstream app. Teams that still manage those grants locally will struggle to answer the two questions that matter most: who approved it, and how fast can it be removed?
Ephemeral delegation debt: Short-lived assertions reduce exposure, but they do not remove the need to track every approved client-server pair as a governed access relationship. The programme risk shifts from secret sprawl to delegation sprawl, which means review, approval, and revocation processes have to move upstream into the IdP.
Cross App Access makes MCP adoption look less like unmanaged shadow integrations and more like a standard access lifecycle problem. For identity leaders, that is useful only if policy ownership, auditability, and revocation workflows are explicit before the integration footprint scales further.
For practitioners
- Inventory every AI client-server pairing Map which MCP clients can reach which downstream tools, what scopes they hold, and which business owners are accountable for each grant.
- Move approval into the IdP policy layer Require allowlists, scope restrictions, and step-up checks before an AI client receives any identity assertion for a downstream server.
- Make revocation a central workflow Remove downstream grants from local administration paths so access can be cut off by disabling the assertion path at the enterprise identity provider.
- Treat assertion validation as a security control Verify audience, expiry, and signed claims on every token exchange so the downstream server only accepts enterprise-approved delegations.
Key takeaways
- AI app integrations become materially easier to govern when the enterprise IdP sits in the delegation path and approves app-to-app access centrally.
- The main risk is not just consent friction. It is invisible delegation that leaves security teams unable to inventory or revoke downstream access cleanly.
- Short-lived assertions help reduce standing privilege, but they only improve control if enterprises validate claims consistently and keep revocation anchored in the IdP.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | MCP client-server delegation creates third-party access paths that must be governed centrally. |
| NHI-05 — Overprivileged NHI | App-to-app grants can easily exceed the scopes needed for a specific AI task. | |
| NHI-07 — Long-Lived Secrets | The article argues for short-lived assertions instead of durable secrets or standing tokens. | |
| Recommendation — Inventory third-party AI integrations and control delegated access through the IdP before granting downstream scopes. Constrain MCP client scopes to the minimum necessary for each approved integration. Replace durable AI integration credentials with short-lived, policy-issued assertions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Cross App Access is fundamentally about governing permissions and delegated authorizations. |
| Recommendation — Centralise entitlement approvals and revocations for AI app-to-app access in the identity provider. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identifier and Authenticator Assurance | The flow relies on trusted federated assertions and validation between systems. |
| Recommendation — Validate federated assertions and downstream token exchanges before issuing resource access. | ||
Key terms
- 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.
- 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.
- Delegated Authorization: A model in which an application is allowed to act on a user’s behalf after explicit approval. In SaaS environments, delegated authorization is powerful but risky because excessive scope or weak revocation can turn a routine integration into durable non-human access.
- Audit Validation: Audit validation is the process of proving that governance controls exist and operate consistently enough to satisfy external review. It focuses on evidence, traceability, and repeatability. In identity programmes, validation does not automatically mean risk has fallen, only that the organisation can demonstrate oversight.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org