Cross App Access on the TrueFoundry MCP Gateway: Identity-Governed Agent Access, Powered by Your IdP

AI agents are quickly becoming the universal remote for enterprise work. They read from Jira, write to Slack, query the data warehouse, open pull requests, and chain a dozen tools together to finish a single task. The Model Context Protocol (MCP) is what makes this possible — it gives agents a standard way to discover and call those tools.

But MCP answers how an agent talks to a tool. It does not answer the question every security team is now asking: which agents are allowed to reach which systems, on whose behalf, with what scope — and who can see and revoke that?

That gap is exactly what Cross App Access (XAA) closes. And it maps almost perfectly onto what an MCP gateway is built to do. This post explains what XAA is, why it matters, and how the TrueFoundry MCP Gateway implements it — turning your identity provider into the control plane for every agent-to-tool connection in your organization.

The problem: agent connections happen outside the identity perimeter

Today, when a user connects an MCP client (an AI app like Claude, Cursor, or VS Code) to an MCP server (Slack, Atlassian, an internal service), the authorization handshake usually happens directly between those two apps. The pattern looks like one of two things, and both are problematic at enterprise scale:

• Static credentials and API keys. Long-lived, frequently over-scoped, scattered across laptops and config files. They rarely get rotated and almost never get revoked cleanly. Every key is standing privilege and blast radius.
• Per-user OAuth consent. Better than raw keys, but it pushes a consent screen at the user for every tool, every client, every time. The corporate IdP authenticated the user into the app — but it never authorized the relationship between the AI client and the tool. From the IdP's point of view, that grant is invisible.

The result is shadow AI: a sprawling, unmanaged web of agent-to-app connections that IT and security teams can neither inventory nor control. Admins can't answer "which AI clients can act in Atlassian as this user, and with what scopes?" — and they can't shut it off in one place when an employee or an agent is offboarded.

TrueFoundry already solves a large part of this by centralizing MCP access through a single governed gateway — one entry point, RBAC down to the tool level, a secure credential vault, and a full audit trail. XAA closes the last gap: it puts the identity provider itself back into the authorization decision, so the same policies that govern the rest of your stack now govern your agents.

What Cross App Access actually is

Cross App Access (XAA) is an extension of OAuth 2.0 that lets an enterprise identity provider mediate and approve the connection between two applications — instead of those two apps establishing trust directly. It was introduced by Okta in June 2025, adopted by the IETF OAuth Working Group in September 2025, and incorporated into MCP in November 2025 as the authorization extension known as Enterprise-Managed Authorization (EMA). That extension reached stable status in June 2026.

A quick terminology note, because you'll see both names in the wild:

• ID-JAG — the Identity Assertion JWT Authorization Grant — is the vendor-neutral OAuth extension being standardized at the IETF. It's the technical blueprint: how an IdP issues a signed identity assertion, what claims it carries, and how an app redeems it.
• XAA is Okta's product name for its implementation of ID-JAG, and the term most people encounter first. In MCP, the same mechanism is surfaced as the Enterprise-Managed Authorization extension.

We'll use "XAA" throughout, but the important point is that this is an open standard. Any IdP can implement ID-JAG, and any MCP server, client, or gateway can support it.

The three roles

XAA defines a clean separation of responsibilities:

The flow

The magic of XAA is that it replaces the manual per-app consent step with a policy-governed token exchange that the IdP brokers:

sequenceDiagram
    participant User
    participant Client as Requesting App
    participant IdP as Enterprise IdP<br/>(Okta)
    participant Resource as Resource App<br/>(MCP server)

    User->>Client: Sign in via SSO (OIDC)
    IdP-->>Client: ID token (proves user identity)
    Client->>IdP: Token exchange — "let me reach this resource for this user"
    IdP->>IdP: Evaluate XAA policy (which apps may connect)
    IdP-->>Client: ID-JAG (signed identity assertion, scoped to target audience)
    Client->>Resource: Present ID-JAG (JWT-bearer grant)
    Resource->>Resource: Validate assertion against IdP's JWKS (same keys as SSO)
    Resource-->>Client: Short-lived, audience-restricted access token
    Client->>Resource: Call the API with the scoped token

Because the resource app already trusts the IdP's signing keys from SSO, no new trust infrastructure is needed. The IdP enforces policy once, issues short-lived scoped tokens, and records every grant — and the user never sees a consent prompt. Authorization decisions move from the application layer to the identity layer, where they're auditable and revocable.

How TrueFoundry implements XAA

An MCP gateway is the ideal place to land XAA, because the gateway already sits in the exact spot where the requesting app meets the resource app. TrueFoundry's authentication architecture was built around a deliberate separation of inbound authentication (how clients prove who they are to the Gateway) from outbound authentication (how the Gateway reaches downstream MCP servers). That separation is precisely the shape XAA needs.

TrueFoundry supports XAA with the Gateway taking on the requesting-app role. Here's the core flow.

The agent sends its Okta token; the Gateway does the exchange

The agent application authenticates the user once with Okta and receives an Okta token. From then on it simply passes that token to the Gateway on each request — it does not need to implement XAA itself or obtain its own scoped assertions. The Gateway handles the rest:

1. Validates the Okta token and resolves it to a TrueFoundry identity (user, team, or virtual account) using the existing Identity Provider configuration and Okta group → team mapping, then enforces tool-level RBAC/ABAC.
2. Performs the token exchange with Okta, requesting an ID-JAG assertion scoped specifically to the MCP server the agent is trying to reach. Okta evaluates XAA policy and returns the scoped assertion — with no additional consent or authorization prompt to the user.
3. Redeems the assertion for a short-lived, audience-restricted access token for that MCP server.
4. Calls the MCP server with the scoped token and streams the result back to the agent.

The user signs in one time, at the agent application. They never see a per-server OAuth consent screen, and the agent never holds standing credentials for any downstream tool.

sequenceDiagram
    participant User
    participant Agent as Agent Application
    participant IdP as Okta (Enterprise IdP)
    participant Gateway as TrueFoundry MCP Gateway
    participant MCP as MCP Server

    User->>Agent: Sign in via Okta SSO (one time)
    IdP-->>Agent: Okta token
    Agent->>Gateway: Call MCP tool + Okta token (inbound auth)
    Gateway->>Gateway: Validate token, resolve identity, enforce RBAC
    Gateway->>IdP: Token exchange — request assertion scoped to target MCP server
    IdP->>IdP: Evaluate XAA policy
    IdP-->>Gateway: ID-JAG (scoped to the MCP server)
    Gateway->>Gateway: Redeem assertion for short-lived, scoped access token
    Gateway->>MCP: Call tool with scoped token (outbound auth)
    MCP-->>Gateway: Result
    Gateway-->>Agent: Result
    Note over User,MCP: No additional consent or authorization from the user

This builds directly on TrueFoundry's existing inbound auth model (Identity Provider tokens and Token Passthrough), with the Gateway acting as the XAA requesting app — performing the token exchange and scoping each assertion to the specific server in play.

Bridging MCP servers that don't speak XAA (the differentiator)

Most MCP servers in the wild — internal services, OpenAPI-wrapped tools, third-party servers — don't implement XAA natively, and many never will. This is where a gateway earns its keep.

Because the Gateway terminates the identity flow centrally, it can put XAA governance in front of any MCP server, whether or not the server supports the standard. Once policy is satisfied and a scoped token is in hand, the Gateway brokers the downstream connection using whatever that server actually understands — per-user OAuth 2.0, client credentials, a shared API key from the secure vault, token passthrough, or custom headers. The MCP server gets enterprise-governed, IdP-in-the-loop authorization without writing a single line of token-exchange code, and you get one consistent XAA control point across your entire tool estate rather than a patchwork of "XAA-ready" and "legacy" servers.

Mapping XAA to capabilities TrueFoundry already ships

What it looks like in practice

Consider a developer who asks Cursor to triage an incident: pull the related Atlassian tickets, check the relevant Slack thread, and summarize the deploy history.

1. The developer signs into the agent application once via Okta SSO, and the agent receives an Okta token.
2. The agent sends that Okta token to the TrueFoundry Gateway with each request. When it needs Atlassian, the Gateway validates the token, confirms the developer's team may reach the Atlassian MCP server and only the read tools they're entitled to, and performs the token exchange with Okta — requesting an assertion scoped to that server. Okta checks policy — is this developer's group permitted to let an AI client reach Atlassian? — and returns the scoped assertion. No consent pop-up.
3. The Gateway redeems the assertion for a short-lived, scoped access token and brokers the call to Atlassian.
4. Every action lands in TrueFoundry's audit log, attributed to the individual identity and the specific agent.
5. When that developer leaves the team, IT deactivates them in Okta. Their — and their agent's — access to every MCP server behind the Gateway is revoked through the same offboarding flow that governs the rest of their apps.

No new keys were minted. No standing privilege was left behind. Security reviewed the policy once, in Okta.

Why TrueFoundry + Okta

Okta groups the XAA ecosystem into three layers: requesting apps (the clients and agents), resource apps (the tools that hold data), and the identity infrastructure and gateway layer that routes and secures the traffic in between. TrueFoundry sits squarely in that third layer.

The pairing is natural and complementary:

• Okta is the control plane. It authenticates users, evaluates which apps may connect, and issues the signed assertions and short-lived tokens that carry policy across domains.
• TrueFoundry is the enforcement and connectivity plane for MCP. It is where the assertions are redeemed, where tool-level RBAC is applied, where non-XAA servers are bridged into the standard, where guardrails run, and where every call is logged.

Together they let an enterprise answer the gating question in every modern AI security review — "can we govern this in our IdP?" — with an unambiguous yes: your identity provider decides which AI clients connect, to which MCP servers, with which scopes, and you can revoke it all centrally.

Getting started

If you're already running TrueFoundry's MCP Gateway, XAA support extends the authentication model you're using today — register Okta as an Identity Provider, map Okta groups to TrueFoundry teams, and bring your MCP servers (XAA-native or not) under one identity-governed front door.

If you're evaluating how to deploy AI agents at scale without inheriting credential sprawl and shadow-AI risk, this is the foundation: standards-based, IdP-mediated, and built on the OAuth and OpenID Connect you already trust.