Cross app access for AI agents shifts authorization to the IdP

At a glance

What this is: This is an analysis of Cross App Access for MCP gateways, showing how identity providers can mediate agent-to-tool authorization instead of leaving it to scattered app-level grants.

Why it matters: It matters because IAM teams need a governable control plane for AI clients, service-style access, and offboarding across tool ecosystems that traditional per-app consent cannot reliably see.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing credentials.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read TruFoundry's analysis of Cross App Access for MCP gateway authorization

Context

MCP gives AI agents a standard way to talk to tools, but it does not by itself answer who may connect which agent to which system, on whose behalf, or with what scope. That leaves a governance gap for AI agent identity, because consent and authorization often happen outside the enterprise identity perimeter.

Cross App Access moves that decision into the identity layer by letting the IdP mediate app-to-app trust through policy-governed token exchange. For IAM, IGA, and PAM teams, that changes the control boundary from individual tool connections to centrally reviewable grants across the agent-to-tool path.

The article frames TrueFoundry’s MCP Gateway as the enforcement point for this model, especially where downstream MCP servers do not natively support the standard. That starting position is typical of enterprise AI adoption: access spreads faster than policy, and the visible problem is not model output but unmanaged authorization paths.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create more IAM risk than ordinary developer tools?

A: AI agents can make independent tool calls, chain actions, and authenticate with non-human identities while executing a task. Ordinary developer tools generally do not decide what to do next. That autonomy increases the chance of unintended access, makes attribution harder, and raises the value of session-level controls that show both intent and outcome.

Q: What breaks when AI client access is governed only by per-app OAuth consent?

A: The IdP cannot see or centrally revoke the relationship between the AI client and the target tool. That creates unmanaged shadow AI, weakens lifecycle controls, and leaves teams unable to answer who can act in which system on whose behalf.

Q: How do organisations decide whether an MCP gateway belongs in their identity architecture?

A: If they need one enforcement point for native and non-native tool servers, the gateway belongs in identity architecture. It can terminate the connection, apply tool-level policy, broker scoped assertions, and preserve a unified audit trail across the AI estate.

Technical breakdown

How XAA changes app-to-app authorization in MCP

Cross App Access, also described as an identity assertion JWT authorization grant, changes the trust model from direct app-to-app consent to IdP-mediated policy evaluation. The requesting app presents a user-backed token, the identity provider evaluates whether that client may reach a specific resource app, and then issues a short-lived assertion scoped to the target audience. In an MCP context, that removes the need for every client-server pair to create its own trust relationship. The resource app still validates the IdP’s signing keys, but the authorization decision is centralized and auditable.

Practical implication: security teams should treat IdP policy as the source of truth for agent-to-tool access, not per-app consent screens.

Why an MCP gateway becomes the control point

An MCP gateway sits at the junction where an agent application reaches downstream tools, so it can separate inbound authentication from outbound authorization. That architecture lets the gateway validate the user token, resolve the identity to a team or virtual account, request a scoped assertion from the IdP, and then redeem it for a short-lived access token to the tool. The gateway also becomes the place to enforce tool-level RBAC and ABAC, which matters when many MCP servers do not natively understand XAA but still need governable access.

Practical implication: centralise enforcement at the gateway if you need one policy plane across native and non-native MCP servers.

Why static credentials and per-user OAuth both fall short

Static API keys create standing privilege and are difficult to revoke cleanly, especially when they are shared across laptops, config files, or automation paths. Per-user OAuth consent improves attribution, but if authorization is handled only between the client and the tool, the enterprise IdP cannot see the relationship or revoke it centrally. In practice that creates shadow AI, where agent-to-app connections exist outside standard lifecycle controls. The core issue is not only credential strength, but whether the identity system can inventory and terminate the grant.

Practical implication: replace invisible app-to-app grants with lifecycle-managed, centrally revocable authorization paths.

Threat narrative

Attacker objective: The attacker or rogue workflow gains persistent, governable-looking access to multiple enterprise tools through an authorization path that the IdP cannot fully see or revoke.

1. Entry occurs when an agent application authenticates a user once and then carries an IdP token into downstream tool access flows.
2. Escalation happens if the agent or gateway can obtain broader tool reach than intended because authorization is not centrally governed or scoped per resource.
3. Impact is unmanaged shadow AI, where tool access cannot be inventoried cleanly, offboarded reliably, or audited across the full agent-to-app path.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Cross-app authorization is the real identity problem in enterprise AI. MCP standardises how agents talk to tools, but it does not by itself decide who is allowed to connect which client to which resource. That missing decision belongs in the identity layer, because scattered per-app grants become ungovernable as soon as agents start chaining tools across the estate. Practitioners should treat app-to-app trust as an identity governance problem, not a protocol convenience.

Standing credential exposure is the wrong operating model for agentic tool use. Static keys and long-lived OAuth grants assume that access remains visible long enough to review and revoke through normal lifecycle processes. AI agents collapse that assumption by creating many short-lived, task-specific connections that are hard to inventory after the fact. The implication is that lifecycle governance has to shift from isolated credential objects to centrally mediated authorization paths.

Identity-blind automation becomes shadow AI the moment tool access outruns policy. When the IdP cannot see which AI client is acting on which resource, the enterprise loses the ability to answer basic questions about scope, approval, and revocation. That is not only a technical issue, it is a governance failure that undermines auditability across IAM, IGA, and PAM. Practitioners should assume every invisible grant is a future offboarding problem.

Cross-app access will increasingly converge with Zero Standing Privilege for non-human identities. If an agent only needs ephemeral access to a specific tool for a specific task, the control objective is not perpetual trust but narrowly scoped, revocable access at runtime. That pushes AI governance toward short-lived assertions, tool-level policy, and centralized audit trails rather than broad inherited entitlements. Teams should align AI access design with NHI governance, not human-app consent habits.

Named concept: identity-governed agent access. This is the control pattern where the IdP, not the agent or the tool, decides whether a client may act on behalf of a user and with which scopes. The concept matters because it collapses fragmented app trust into one reviewable policy boundary. Practitioners should use it as the design lens for MCP gateways and enterprise AI rollout.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• That governance gap is why OWASP Agentic Applications Top 10 is becoming a practical reference point for policy, scope, and tool-use controls.

What this signals

Identity-governed agent access will become the default design question for enterprise AI programmes. Once agents can reach multiple tools from one user session, the control problem moves from app-by-app consent to centrally mediated scope, audit, and revocation across the delegation chain.

With 98% of companies planning to deploy more AI agents within 12 months, per AI Agents: The New Attack Surface report, the programme risk is not whether AI will spread, but whether identity can still see it. Teams that cannot inventory grants will struggle to prove least privilege or support offboarding.

MCP gateways, XAA, and the OWASP Agentic AI Top 10 all point to the same operational shift: authorisation is moving closer to runtime behaviour. Security leaders should expect more pressure to unify IAM, IGA, and NHI controls around short-lived assertions and central policy enforcement.

For practitioners

• Centralise agent-to-tool authorization in the IdP Map every AI client, MCP server, and downstream tool to a single policy layer so app-to-app trust is no longer invisible to IAM or audit teams.
• Eliminate standing credentials from agent workflows Replace shared keys and long-lived tokens with short-lived, audience-restricted assertions and keep any unavoidable secrets in a governed vault.
• Tie agent access to lifecycle events Make offboarding, role change, and group removal revoke the same grants that power user-backed AI access so access cannot outlive accountability.
• Build a complete audit trail for every tool call Record which human, which agent, which tool, and which parameters were involved so compliance teams can reconstruct agent activity without relying on scattered app logs.

Key takeaways

• Agent-to-tool trust is now an identity governance problem, not just a protocol detail, because AI clients can spread access faster than per-app consent can be reviewed.
• Centralised authorization at the IdP gives security teams the missing visibility and revocation point needed to manage shadow AI and offboarding.
• Short-lived, scoped assertions and gateway-based enforcement are the practical controls that turn AI access from standing privilege into governable runtime 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.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Audience-bound token: An access token that can only be used against a specific resource server or API. Audience binding limits replay, reduces token portability, and ensures that a credential minted for one task cannot be reused elsewhere.

What's in the full article

TruFoundry's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step XAA token exchange flow between the agent, the IdP, and the MCP Gateway.
• Gateway validation and outbound redemption logic for both XAA-native and non-native MCP servers.
• Okta group-to-team mapping and the exact identity resolution model used to scope tool access.
• Examples of request logging, guardrails, and approval workflows for high-risk write operations.

👉 TruFoundry's full post covers the XAA flow, gateway enforcement model, and tool-level access mapping.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, IGA, or PAM programme, it is worth exploring.