Identity Is the Control Plane: Okta’s XAA Playbook

The identity control plane moment

AI agents are not just another integration pattern. They are a new kind of principal that acts on data, initiates actions across SaaS apps, and composes workflows at machine speed. That shift exposes a gap. OAuth and SSO were designed to let humans sign in and consent to a single app. Agents operate differently. They connect to many apps, they persist, and their scopes need to be managed centrally rather than scattered across one off grants.

Okta put a spotlight on this at Oktane 2025, positioning identity as the control plane for agents and introducing Cross App Access, or XAA, as the policy and authorization backbone for agent to app interactions. For a quick backstory, see TechRadar’s Oktane 2025 coverage. The gist is simple. Identity has to govern not just humans, but the growing population of non human identities that now includes autonomous and semi autonomous agents.

Why agent sprawl is different from shadow IT

Shadow IT used to mean an unsanctioned app with a handful of users. Agent sprawl looks similar at first, but the risk profile is different:

Agents chain across apps by default. A helpful assistant that reads documents, posts updates, and files tickets needs simultaneous access to storage, chat, and ITSM. The blast radius is wider. Threat models are evolving with agent hijacking risks that magnify the impact of over scoped tokens.
Consent is fragmented. Today, agents often rely on user consent pop ups for each destination app. This produces a brittle maze of long lived tokens that security teams cannot see or revoke centrally.
Autonomy introduces ambiguity. An agent can initiate actions on a schedule or based on triggers. That makes traditional, human centric approval gates and audit trails incomplete unless identity becomes the unifying layer.

The result is gaps in governance, least privilege, and observability. Without a control plane, it is hard to answer simple questions like which agents can read which datasets or who approved the agent posting in a production channel.

What Cross App Access is trying to fix

Cross App Access extends OAuth so that the identity provider, rather than each destination app, becomes the authority that brokers and records agent to app connections. Instead of chasing consents one app at a time, security teams can define and enforce policy centrally. Two things change as a result:

A new relationship type emerges. In addition to human to app assignments, you manage agent to app relationships with explicit, admin approved connections. You can see them, search them, and revoke them in one place.
Tokens represent policy, not just consent. Tokens get minted under enterprise policy that encodes who the agent acts for, which app is the resource owner, what actions are allowed, and under what conditions. This makes least privilege something you can actually enforce at scale.

How XAA works at a glance

Under the hood, Cross App Access introduces an identity centric authorization flow that lets a requesting app, the agent, obtain an access token to a resource app with the identity provider mediating the trust. In Okta’s implementation you will see new concepts such as a requesting app, a resource app, and a managed connection between them, along with a token exchange pattern that is purpose built for this use case. For a practical breakdown of these pieces and the token dance, see Okta documentation for Cross App Access.

What matters for operators is the control surface you gain:

Managed connections. You explicitly connect Agent A to App B under policy, rather than relying on a user to click consent in App B.
Policy driven scopes. You define which APIs the agent can call on behalf of which users or groups, and you bind that to context like network, device posture, or time of day.
Central visibility. You can report on every connection an agent has across your portfolio, and you can sever any single link without hunting for a token buried in a third party app.

How XAA complements the Model Context Protocol

The Model Context Protocol, MCP, standardizes how models discover tools, exchange messages, and call functions across servers. It boosts interoperability for agent capabilities. But MCP is deliberately scoped to communication and tool interfaces, not enterprise authorization. Think of MCP as the wiring that lets agents talk to tools. Think of XAA as the breaker panel that decides which circuits are on, how much current they can draw, and who is allowed to flip the switch. Recent platform updates like Apple lays MCP rails signal how quickly this wiring is spreading across ecosystems.

MCP improves transparency and capability discovery. XAA adds enforceable access boundaries.
MCP helps a model know that a file search tool exists and how to call it. XAA determines whether the agent is allowed to retrieve files from a particular tenant and dataset under a given user context.
MCP logs requests within its runtime context. XAA makes those requests visible at the identity layer where security teams already manage audits and attestation.

Use both. MCP to evolve the agent platform. XAA to make that platform governable in an enterprise.

How XAA differs from payments focused protocols

Security teams sometimes analogize agent authorization to payments. After all, both involve delegation, risk, and policy. The similarities are helpful, but the differences are crucial:

Transactionality vs continuity. Payment flows are episodic. A token is issued for a single transaction or tightly bounded session. Agent access is continuous. An agent may need stable, renewable access to perform a daily sync or respond to events.
Consent semantics. Payments center on explicit payer consent for a single transfer. Agent governance centers on explicit admin consent for a durable relationship between an agent and a resource app, often on behalf of many users.
Scope granularity. Payment scopes resolve to amounts, merchants, and payment instruments. Agent scopes resolve to application resources and methods across many APIs. You need fine grained authorization that maps to data surfaces, not just currency limits.
Visibility and recourse. Card networks and banking rails provide ecosystem wide dispute and trace processes. In SaaS, there is no equivalent network arbiter. You need visibility and revocation anchored in your identity provider.

On the payments side, work like Google’s agent payments protocol addresses how agents pay, but it does not solve enterprise authorization for data rich operations inside SaaS.

If you copy payment style consent screens into enterprise agents, you will end up with token sprawl and limited oversight. If you anchor authorization in identity with XAA, you can keep the user experience smooth without sacrificing governance.

What governance looks like with identity as the control plane

When identity becomes the control plane, three outcomes get easier:

Least privilege by default. Approvals move from users to administrators and from per app to central policy. Scopes shrink to exactly what the agent needs.
Unified auditing. Every connection is visible at the identity layer, which means a single place to answer who can do what and when that permission was granted.
Safer automation. Agents are fast. Central policy lets you add break glass approvals, step up verification, or human in the loop gates for sensitive actions without rewriting each agent.

A near term rollout playbook for CISOs and platform teams

You do not need to boil the ocean to get value. The following plan assumes you are starting now, with a mixed environment of sanctioned AI helpers and DIY automations.

Form a joint squad

Create an identity plus platform plus security squad with a single backlog. Include the owners of your IdP, your API gateway, the teams building or buying agents, and audit or compliance.

Inventory agents and apps

Catalog every agent, internal and vendor supplied. Capture purpose, acting user context, data touched, destination apps, and existing tokens. Tag each agent to a business owner and a technical owner.
Classify data surfaces by sensitivity. Files, chat, ticketing, code, CRM, finance, and HR all carry different risk.

Define risk tiers and policy guardrails

Tier agents based on the actions they can take, not just the data they read. An agent that can create tickets is different from one that can close them.
Draft policy primitives that you can enforce at the IdP. Examples include allowed resource apps per agent, allowed scopes per API, allowed acting users or groups, time and network conditions, and step up rules for sensitive methods.

Pick two pilot use cases

Choose one read heavy scenario with a clear productivity win, like document summarization in customer support. Choose one write or action heavy scenario, like filing tickets with limited fields.
Ensure both pilots touch common enterprise apps so you test the integration pattern and not an edge case.

Land the XAA model in your IdP

Register agents as first class clients. Create resource app entries for the SaaS or internal APIs they need to call.
Establish managed connections between each agent and each resource app. Bind those connections to policy.
Replace long lived tokens with centrally issued tokens governed by identity policy. Rotate anything left over.

Align agent identity with human identity

Bind each agent action to an accountable human or team identity. Use group based assignments so that access follows role changes. For shared agents, model the acting user context explicitly so authorization checks downstream can still pass.

Build the observability loop

Instrument logs at the IdP and at gateway edges to attribute requests to agent identities, acting users, and resource apps. Normalize these events into a single timeline per agent.
Define health and risk signals. Examples include unexpected scope expansion, spikes in calls to sensitive methods, repeated failures on permission checks, and off hours activity.
Send high value events to your SIEM and to dashboards used by product owners, not just security.

Add human controls where they matter

Introduce step up verification for especially sensitive write operations. Use just in time approval for actions like deleting a repository or mass updating CRM records.
Record who approved the action and why as part of the identity audit trail.

Bake in lifecycle management

Treat agents like employees for joiner, mover, leaver events. When a team changes ownership or a project ends, manage their agent access through identity driven deprovisioning, not manual token hunts.

Prove compliance early

Map your identity controls to the frameworks that matter to you. SOC 2, ISO 27001, HIPAA, or regional regulations often require auditable access reviews and least privilege. Show evidence using your IdP audit logs and policy definitions.

Expand responsibly

After your pilots, add more resource apps and more scopes but keep the same playbook. Avoid per agent one offs by building a reusable policy library and a connection approval workflow.

Architecture, at a glance

Picture a hub and spoke model controlled by identity:

The agent is a requesting app and authenticates to the IdP. It proves who it is and who it is acting for, for example a user or group.
The IdP evaluates policy for the managed connection between the agent and a resource app. It mints a token that encodes that result.
The resource app validates that token and enforces its own authorization checks aligned with the scopes in the token.
Observability is stitched through the IdP, the API gateway or service mesh, and the agent runtime, so you can reconstruct the full story of what happened.

This architecture moves the control surface into a place you already own, your identity layer, which is where your analysts and auditors are already comfortable.

What to watch next

Ecosystem breadth. The power of an authorization protocol grows with the number of resource apps that speak it. Track app catalog coverage and how easy it is to onboard your internal APIs.
Cross tenant flows. Many enterprises operate multiple tenants and partner orgs. The ability to form managed connections across boundaries without brittle custom work will be a differentiator.
Deeper policy context. Expect tighter coupling with device signals, data classification tags, and workload identity so that agent access can reflect risk at runtime.
Standard alignment. Watch how XAA implementations align with broader identity standards groups and how they interoperate with agent frameworks that already support MCP.

The bottom line

The future of enterprise AI will not be decided only by model quality. It will be decided by whether organizations can let agents act on their behalf without losing control. Extending OAuth with an identity mediated control plane is a pragmatic answer. It curbs agent sprawl, makes least privilege real, and puts a single pane of glass over who can do what across your apps.

If you run security or platform, you do not have to wait. Start with two pilots and a clear policy library, register agents as first class identities, connect them to the apps they need through managed connections, and build the observability loop. Identity becomes the gear shift and the brakes, not just the ignition. That is how you make AI safer and faster at the same time.