---
title: "Zuplo Joins Okta's Cross App Access (XAA) Ecosystem"
description: "Zuplo is a launch partner in Okta's Cross App Access ecosystem. Here's what XAA is, why it matters for AI agents, and how agent traffic now flows through Okta's identity engine at the gateway."
canonicalUrl: "https://zuplo.com/blog/2026/06/23/zuplo-okta-cross-app-access-launch-partner"
pageType: "blog"
date: "2026-06-23"
authors: "josh"
tags: "Model Context Protocol, ai-agents, product"
image: "https://zuplo.com/og?text=Zuplo%20Joins%20Okta%27s%20Cross%20App%20Access%20%28XAA%29%20Ecosystem"
---
Your teams are wiring AI agents into Linear, GitHub, Stripe, and a pile of
internal servers right now. How are those agents authenticating? For most of
them, the answer is a static API key in a config file, with nobody on the
security team able to see it, scope it, or revoke it.

That gap is the whole problem. IBM's
[2025 Cost of a Data Breach report](https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls)
found that 97% of organizations reporting a breach involving AI lacked proper AI
access controls. The agents aren't going rogue. The governance just isn't there.

Today we're proud to announce that Zuplo is a launch partner in Okta's
[Cross App Access](https://www.okta.com/solutions/cross-app-access/) (XAA)
ecosystem, one of 25+ early adopters of the identity protocol that secures how
AI agents connect to the tools we use every day.

<CalloutAudience
  variant="bestFor"
  items={[
    "Platform teams putting AI agents in front of internal and third-party APIs",
    "Security and IT teams who need to govern agent access centrally",
    "Developers building MCP servers that have to pass an enterprise security review",
  ]}
/>

## What Cross App Access (XAA) actually is

XAA is an open, vendor-neutral protocol that secures agent-to-app and
app-to-app connections. It extends OAuth, the standard your APIs already speak,
and moves the access decision out of each individual app and up into the
identity layer.

Most of that connecting happens over MCP, the Model Context Protocol agents use
to discover and call tools. The MCP spec added an authorization extension for
exactly this,
[Enterprise-Managed Authorization](https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/)
(EMA), which went stable on June 18, 2026. Cross App Access (XAA) is Okta's
implementation.

The OAuth still happens, but it's brokered centrally. An administrator sets the
policy once in Okta, and when a person signs in to their agent, that agent
connects to the servers they're allowed to reach instead of hitting a consent
screen for every one. The identity provider, not each app, decides what an agent
can touch.

Okta is the first supported provider, with XAA shipping in the TypeScript and
Java SDKs first and Python on the way.

If you've followed our work on
[MCP authorization](/blog/fine-grained-authz-ai-agents), this is the missing
enterprise piece slotting into place: a standard answer to "what is this agent
allowed to connect to?" rather than a custom one per server.

## Where Zuplo fits in the XAA ecosystem

Zuplo is the infrastructure layer. Agent traffic passes through gateways, MCP
servers, and orchestration layers, and that's exactly where we live. Through
Cross App Access (XAA), Zuplo routes and governs that traffic through Okta's identity
and policy engine, so the agent only ever reaches what your Okta policies allow.

This extends what the
[Zuplo MCP Gateway](/blog/introducing-zuplo-mcp-gateway) already does. The
Gateway ships a full OAuth authorization server with first-class presets for
Okta and other providers, so the auth machinery XAA depends on is already
running in front of your MCP servers. Customers plug in and get a standardized
way to manage agent traffic at enterprise scale.

## What you get as a developer

1/ **An open protocol, no lock-in.** XAA is OAuth-based and vendor-neutral.
You're adopting a standard, not a proprietary integration.

2/ **Okta's policy engine, directly.** Agent access follows the same
identity-based rules your workforce already uses. No custom AI governance layer
to build and maintain.

3/ **Short-lived, scoped tokens.** Hardcoded credentials in agent configs get
replaced with tokens that expire and carry only the scope they need. The kind of
[token hygiene](/blog/bind-mcp-tokens-to-one-server) that survives a security
review.

4/ **A full audit trail out of the box.** Every agent connection is attributable
and revocable. When IT needs to cut off access, they can do it instantly.

## Available through the Okta Integration Network in August

Okta Workforce customers can begin accessing supported XAA applications through
the [Okta Integration Network](https://www.okta.com/integrations/) starting in
August 2026. If you're already running MCP servers behind a gateway, governing
agent access centrally is exactly the kind of thing
[enterprises have been asking for](/blog/why-enterprises-need-an-mcp-gateway).

<CalloutDoc
  title="MCP Gateway Quickstart"
  description="Stand up a virtual MCP server with OAuth wired in, point an agent at it, and watch every call land in your analytics."
  href="https://zuplo.com/docs/mcp-gateway/quickstart"
  icon="book"
/>

Securing how agents connect is core to the agentic enterprise: knowing where
your agents are, what they connect to, and what they're authorized to do. XAA
answers the middle question, and we're glad to be building it alongside Okta and
the rest of the launch partners.

Read
[Okta's announcement](https://www.okta.com/newsroom/press-releases/okta-announces-cross-app-access-partners)
for the full partner list, then
[spin up a free Zuplo project](https://portal.zuplo.com/signup?utm_source=zuplo-blog&utm_medium=web&utm_campaign=xaa-launch)
and put your MCP servers behind a gateway that already speaks Okta.