AI agents are starting to do real work inside the enterprise. Think of a product manager querying Anthropic's Claude to draft a launch-readiness summary. Or a developer asking an agent in Cursor or VS Code to check deployment status.
Users rarely see most of the transactions happening underneath, and that's a problem. The handshake between an
AI agent and the enterprise application typically happens outside the view of the IT and security teams responsible for governing it.
"There's a lot of stuff we've been doing for years that we've gotten away with because of the scale that's happened," says Aaron Parecki, Director of Identity Standards at identity and access management provider Okta. "A lot of the stuff around AI is new, but at the same time, it's not actually that it's new; it's just happening faster."
For years, static API keys and standing privileges were an acceptable trade-off: clunky, but manageable. AI agents have changed that math.
The volume and speed of machine-to-machine requests hitting enterprise applications now outpaces what those legacy controls were built for, and the gap between what security teams can see and what's happening has widened into a real blind spot.
The visibility gap
When an AI agent requests data from an enterprise app on a user's behalf, it gets there through
OAuth, the open identity protocol behind most enterprise login and authorization flows. Somewhere in that flow, the user logs into the organization's
identity provider; a routine sign-in is what shows up in the admin's logs.
What the logs don't show is the next step: the app granting an access token to the agent itself.
That connection was not negotiated through the enterprise identity provider, so it never surfaces in the admin's view.
A handful of more sophisticated applications build their own visibility tools so their administrators can see which agents are granted access. But most don't. Even where the data exists, it's scattered application by application, rather than consolidated where the enterprise identity team can see it.
"That's the blind spot," Parecki says. "Your actual admin who is overseeing what enterprise resources exist and who can talk to what. There's this massive blind spot of not being able to see what agents are actually connecting to the applications."
Why open standards, not a proprietary fix
This visibility shortfall extends an older shift from the network perimeter as the primary security boundary toward identity. SaaS adoption has already pushed enterprises past the point where a network edge can meaningfully contain access. Parecki argues that AI agents simply complete the logic, extending identity-based controls to non-human identities — including agents.
That's the gap targeted with
Cross App Access (XAA), formally known as the Identity Assertion Authorization Grant. The protocol,
announced at Oktane 2025, routes agent-to-app and app-to-app connections through the enterprise identity provider so that each request is scoped, governed by policy, and logged.
Okta is expanding the XAA ecosystem with 20 new integrations, bringing the list of early adopters to 25 companies spanning AI agents, enterprise applications, and the infrastructure layer that routes traffic between them.
Rather than introducing a proprietary system, XAA was built as an extension of OAuth. The protocol has been formally incorporated as an official
Model Context Protocol (MCP) authorization extension.
"There's a lot of infrastructure that exists out there built around the primitives described in OAuth and now also MCP," Parecki explains. The alternative — asking every application to build new infrastructure from scratch — was, he adds, too much of an ask.
Because most enterprise applications already run their own OAuth servers, adding a new grant type to existing infrastructure, rather than standing up something new, means the largest number of participants do the least amount of new work.
It's also, by design, not a one-vendor effort. Parecki has spent much of the past year working on the standards side of this problem at venues and conferences, gathering practices from across the industry rather than dictating one company's approach.
"Okta's not the only one driving this," he says.
The XAA spec lives inside OAuth and MCP, which are protocols that no single vendor owns. As such, any identity provider, not just Okta, can implement it, and any application can choose to support it.
The issue of least privilege
Under conventional OAuth, re-authorizing an agent every time it needs a different scope is disruptive enough that most organizations skip the friction and grant broad access up front — creating a large security risk
XAA removes the user from token issuance entirely, so an agent can request a down-scoped, short-lived token, such as read-only one. If the agent needs more tokens, it can ask again later, with no user-facing prompt.
That doesn't mean gaps don't remain. Token lifetime is still set by the application issuing the token, not the identity provider. The policy engine can govern what's granted but not how long it lasts. That's still an issue the industry needs to solve.
Start with business-critical issues ready for integration
Cybersecurity teams should identify which business-critical applications AI agents are already connecting to the most, then check which of those are XAA-ready. For applications not yet supported, push partners directly since vendors tend to prioritize protocol support when customers ask for it.
The pace of organic adoption is a signal in itself. Many of the 25 participating companies have been testing XAA's open tooling for more than a year after watching the standard take shape at industry events like
Identiverse.
"We can write documents all day long, but if nobody builds this stuff, it doesn't matter," Parecki says. "Actually seeing it being built into real products that we use every day [is] super exciting and super validating to see that this is actually paying off."
That said, overprivileged AI agents are a problem that no single launch can solve. Tools will keep wanting more data, agents will keep multiplying, and that access will keep needing governance and regulation.
The agent-to-agent connections happening across enterprises right now aren't going away. The practical task for security teams is making them visible through the XAA protocol and whatever may eventually supersede it.
