Skip to main content
With Cross App Access (XAA), Runlayer gets the access token for an upstream MCP server from your Okta policy, not from a consent screen each user clicks through. Your Okta admin approves Runlayer’s connection to each vendor once, the vendor trusts your Okta org, and users call tools with no consent prompts.
Cross App Access is in early access. Contact your Runlayer account team to enable it for your organization.

​
Why XAA

Standard OAuth leaves the security decision to each user. XAA moves it to your admins.
  • No consent screen to phish. With standard OAuth and open dynamic client registration, any client can register under any name, and the only control is the user’s consent click. That is the pattern behind illicit consent grant attacks. With XAA there is no consent screen for an attacker to imitate.
  • Admin policy instead of user consent. Your Okta admin decides which users and groups can use Runlayer with which vendor. The vendor admin decides to trust your Okta org.
  • The right account, every time. With standard OAuth, the user picks which vendor account to connect, so a corporate Runlayer identity can end up paired with a personal or other-org account. With XAA, Okta asserts the user and the vendor maps that assertion to the org-managed account. Audit attribution stays consistent, data stays in your tenant, and offboarding a user in Okta cuts their access.
  • Verifiable identity. The vendor identifies Runlayer by a client ID metadata document (CIMD) URL on your Runlayer domain, not by a self-reported name.
  • One kill switch and one audit trail. Okta logs every assertion it issues. Removing the Runlayer connection to a vendor in Okta stops access for every user at once.

​
How it works

XAA builds on the Identity Assertion JWT Authorization Grant and the MCP Enterprise-Managed Authorization extension. Runlayer is the requesting app, and each upstream vendor is a resource app.
  1. A user’s AI client calls a tool on a Runlayer connector.
  2. Runlayer applies its policies and guardrails as usual.
  3. Runlayer asks Okta for an identity assertion (ID-JAG) for that user, addressed to the vendor. Okta issues one only if an admin connected Runlayer to that vendor and the user is allowed.
  4. Runlayer redeems the assertion at the vendor’s authorization server and receives a short-lived access token for that user. Runlayer caches the token until it expires.
  5. Runlayer calls the vendor’s MCP server and returns the result.
Approval lives in three places, and none of them is a per-user consent screen:

​
Supported features

  • Outbound XAA from Runlayer to upstream MCP servers. Runlayer requests and redeems identity assertions for each user, with no consent prompts.
  • Okta as the identity provider. Microsoft Entra ID does not issue identity assertions for XAA, so Entra organizations keep standard OAuth.
  • Upstream vendors. Any MCP server whose authorization server supports the identity assertion grant. See Supported vendors.
  • Audit. Runlayer records each assertion request and token redemption in Audit Logs, and Okta records each assertion in its System Log.

​
Limitations

  • Okta enables Cross App Access through Okta Support. Ask Okta to enable it for your org if it isn’t on.
  • Okta limits how many identity assertions it issues per user, per resource app, per month. Runlayer caches the vendor’s access tokens to stay well within that limit.
  • An XAA connector never falls back to OAuth consent. If an exchange fails, the tool call fails with an error that names the cause. See Troubleshooting.
  • Vendors’ enterprise-managed authentication features can be in beta and their scopes can change. Check the vendor’s documentation.
  • Each vendor decides which requesting apps it accepts. Some vendors’ guides currently name only specific AI clients. Contact your Runlayer account team for the current status of a vendor.

​
Supported vendors

These MCP servers support enterprise-managed authentication with Okta. Each vendor has its own plan requirement and admin setting; the setup steps for each are in step 3. In every case, the vendor’s app must already be in your Okta org with your users assigned.

​
Prerequisites

  • An Okta org with the Single Sign-On product and Cross App Access enabled.
  • Your users sign in to Runlayer with Okta.
  • Cross App Access enabled for your Runlayer organization (early access).
  • Admin access in Okta, in Runlayer, and in each vendor you connect.
  • A vendor plan that supports enterprise-managed authentication. See Supported vendors.

​
Configure Cross App Access

1

Add Runlayer to Okta

  1. In the Okta Admin Console, go to Applications → Applications → Browse App Catalog, search for Runlayer, and click Add Integration.
  2. Enter your Runlayer domain, for example acme.runlayer.com.
  3. Make sure the app’s sign-in redirect URIs include https://<your-runlayer-domain>/api/v1/xaa/link/callback. Runlayer uses it to connect each user’s Okta account.
  4. On the Assignments tab, assign the users and groups who should use Runlayer.
Users must be assigned to the Runlayer app before Okta issues identity assertions for them.
2

Connect Runlayer to each vendor in Okta

Each connection is a one-way approval: Runlayer may request assertions for this vendor.
  1. Open the vendor’s app in Okta (the app you use for single sign-on to that vendor). On its Resource server tab, turn on Cross App Access (XAA) and enter the issuer and audience values from the vendor’s tab in step 3, where the vendor lists them.
  2. Open the Runlayer integration, or its AI agent under Directory → AI Agents if your org uses AI agents, and add a Resource connection.
  3. Select the vendor’s application instance.
  4. For the client ID registered at the vendor, enter Runlayer’s client ID metadata document URL:
    If the vendor issues its own client ID to Runlayer instead, enter that one. The vendor’s tab in step 3 says which.
  5. Choose the scopes to allow, and save. If the vendor’s tab says to allow all scopes, do that; the vendor enforces scopes itself.
3

Turn on enterprise-managed authentication at the vendor

Each vendor’s guide is linked in Supported vendors. Do the vendor step before you test the connection in Runlayer.
Follow Asana’s cross-app access guide to trust your Okta org, then return to step 4.
4

Set the connector to Cross App Access in Runlayer

  1. In Runlayer, add the vendor’s connector from the catalog or open an existing one, and go to its Settings. Use the MCP server URL from Supported vendors.
  2. Choose Cross App Access (XAA) as the authentication method. Runlayer pre-selects it when the upstream server supports XAA.
  3. Leave the scopes blank. Runlayer discovers them from the vendor.
  4. Click Test connection. Runlayer checks each stage: discovery, the Okta exchange, the vendor redemption, and listing tools.
  5. Save the connector.
5

Users connect their Okta account on first use

The first time a user calls a tool on an XAA connector, Runlayer asks them to connect their Okta account, so it can request assertions for them. Clients that support link prompts (Claude Code, Codex, Cursor, VS Code) show a prompt that opens the link. Other clients return a tool error that contains the link. Until the user connects, the connector lists a single AUTH_REQUIRED_<connector> tool that returns the same link.The link opens Runlayer, which sends the user through a normal Okta sign-in. If they’re already signed in to Okta, it completes without a prompt. Okta returns them to Runlayer, which confirms whether the account is connected. Each user connects once, and that connection covers every XAA connector. There is no consent screen. The user may need to reconnect the MCP server in their client to see the connector’s tools.
6

Verify

  1. As an assigned user, call a tool on the connector from any AI client connected to Runlayer. Open the link Runlayer offers, and sign in to Okta if asked. No consent screen appears.
  2. Call the tool again. It runs with no prompt.
  3. In Runlayer Audit Logs, find the XAA token exchange for that user and connector.
  4. In the Okta System Log, find the matching identity assertion issued to Runlayer.

​
Lock down other paths

An XAA connection adds a governed path. It does not close the others: a user can still add the vendor’s MCP server to their AI client directly and click through the vendor’s consent screen. To make Runlayer the only path to a vendor, lock down each layer. AI Watch can’t see connectors that an AI client hosts in its own cloud. The AI client’s connector allowlist covers those. With these in place, removing Runlayer’s connection to a vendor in Okta revokes every user’s agent access to that vendor.

​
Sign in to Runlayer

Runlayer supports sign-in that starts from Runlayer:
  1. Go to your Runlayer domain, for example https://acme.runlayer.com.
  2. Click Sign in. Runlayer redirects you to Okta.
  3. Sign in to Okta. Okta returns you to Runlayer, signed in.

​
Troubleshooting

For anything else, contact support@runlayer.com with the connector name, the time of the failed call, and the error message.

​
Learn more