TrueFoundry MCPゲートウェイにおけるクロスアプリアクセス：ID統制型エージェントアクセス、あなたの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? — スコープ付きアサーションを返します。同意ポップアップは表示されません。
3. ゲートウェイはアサーションを短期間有効なスコープ付きアクセストークンと交換し、Atlassianへの呼び出しを仲介します。
4. すべてのアクションはTrueFoundryの監査ログに記録され、個々のIDと特定のエージェントに紐付けられます。
5. その開発者がチームを離れると、IT部門はOktaでそのアカウントを無効にします。その開発者（およびそのエージェント）のGatewayの背後にあるすべてのMCPサーバーへのアクセスは、他のアプリを管理するのと同じオフボーディングフローを通じて取り消されます。

新しいキーは発行されませんでした。永続的な特権は残りませんでした。セキュリティ部門はOktaで一度ポリシーを確認しました。

TrueFoundry + Okta

OktaはXAAエコシステムを3つのレイヤーに分類します。 リクエスト元アプリ （クライアントとエージェント）、 リソースアプリ （データを保持するツール）、そして IDインフラストラクチャおよびゲートウェイ層 その間のトラフィックをルーティングし、保護するものです。TrueFoundryはまさにこの第3のレイヤーに位置します。

この組み合わせは自然で相補的です。

• Oktaはコントロールプレーンです。 ユーザーを認証し、どのアプリが接続できるかを評価し、ドメインを越えてポリシーを伝達する署名付きアサーションと短期間有効なトークンを発行します。
• TrueFoundryはMCPの強制および接続プレーンです。 アサーションが交換され、ツールレベルのRBACが適用され、非XAAサーバーが標準にブリッジされ、ガードレールが実行され、すべての呼び出しがログに記録される場所です。

これらを組み合わせることで、企業は現代のあらゆるAIセキュリティレビューにおける重要な問いに答えることができます — 「これを当社のIdPで管理できますか？」 — 明白な はい：IDプロバイダーが、どのAIクライアントがどのMCPサーバーにどのスコープで接続するかを決定し、それらすべてを一元的に取り消すことができます。

利用開始

すでにTrueFoundryのMCPゲートウェイを運用している場合、XAAサポートは既存の 認証モデル を拡張します。OktaをIDプロバイダーとして登録し、OktaグループをTrueFoundryチームにマッピングすることで、MCPサーバー（XAAネイティブであるか否かにかかわらず）を、IDによって統制された単一のフロントドアの下に統合できます。

認証情報の乱立やシャドーAIのリスクを抱えることなく、AIエージェントを大規模に展開する方法を検討されているのであれば、これがその基盤となります。標準ベースで、IdPを介し、お客様がすでに信頼しているOAuthおよびOpenID Connectに基づいて構築されています。