Okta made Agent SSO generally available on August 24, folding the open Cross App Access standard into its core SSO product so AI agents get registered as first-class identities in Universal Directory, right next to human employees, and issued short-lived tokens instead of static API keys. It's a real fix for a real problem: standing credentials that outlive any single agent task. It is not, on its own, a complete answer to agent governance, since coverage depends on both the agent and the destination app supporting the same protocol. Here's what actually shipped, what it fixes, and what it still leaves open.
The gap Okta is responding to
Enterprises are deploying AI agents faster than they can govern them. Per Okta's own AI Agents at Work 2026 report, only 34% of organizations apply the same security controls to AI agents that they apply to human workers. Most agents today reach enterprise data through static API keys, one-off OAuth grants, and custom integrations built application by application. They show up as anonymous traffic: no owner, no policy, no audit trail.
That gap compounds because organizations are actually managing three separate populations of agents at once: the ones they built in-house, the ones embedded in software they bought, and the ones employees quietly deployed without asking anyone. Agent SSO is aimed squarely at the first problem in that list: credentials.
What Agent SSO actually does
When an agent that supports the open Cross App Access (XAA) standard connects to an enterprise application, Okta registers it as a first-class identity in Universal Directory, the same directory that holds human employee records. From there, Okta issues short-lived, identity-governed tokens for that connection instead of a stored, static API key.
Administrators assign, monitor, and update agent policy through the same console and workflows they already use for employees. If an organization deploys Anthropic's Claude, for example, security teams can govern its access the same way they'd govern a contractor's laptop: named identity, scoped policy, revocable access.
Cross App Access itself is protocol-level, not Okta-specific. It extends OAuth and has been formally incorporated as the official Enterprise-Managed Authorization extension for the Model Context Protocol, which means the identity-and-policy-follows-the-agent model isn't locked to one vendor's stack. Okta says the protocol isn't limited to AI agents either; it covers any case where one application acts on behalf of a user, like syncing meeting notes from Zoom into Asana.
Agent SSO ships at no additional cost inside core Okta SSO plans, which matters for adoption: this isn't a new line item, it's a default that flips on for the 20,000-plus organizations already running Okta SSO.
What it doesn't cover
This is the part worth reading past the press release for. Independent coverage of the launch has been quick to point out that Agent SSO's static-key replacement is specific to compatible flows, not universal. If an agent doesn't support Cross App Access, or the destination app or MCP server on the other end doesn't either, Agent SSO can't unilaterally change how that connection authenticates. Those unsupported pairings still need a different integration, a different control, or legacy credentials, at least for now.
Okta lists out-of-the-box ecosystem support for Anthropic (Claude), Archestra.AI, Asana, Atlassian, Canva, Datadog, Figma, Glean, Granola, Linear, MintMCP, Notion, Slack, and Supabase, but that list is ecosystem participation, not a guarantee that every product edition, every agent-to-resource pairing, and every deployment state is covered identically.
There's also a scope boundary worth understanding before you assume Agent SSO is a full governance layer:
| Layer | What it does | What it doesn't do |
|---|---|---|
| Agent SSO | Registers XAA-compatible agents as identities, issues short-lived tokens for supported connections | Doesn't discover agents that aren't already connecting through XAA |
| Cross App Access (protocol) | Governs the supported agent-to-app and app-to-app connection itself | Doesn't judge what the agent does with access once granted, no per-prompt or per-tool-call oversight |
| Okta for AI Agents (separate product) | Discovers shadow and unregistered agents, extends governance to non-XAA resources, handles access certification and a kill switch | Sold separately from core SSO; the cited launch materials don't publish a universal price |
Worth noting on that kill switch: Okta's own documentation describes it as a manual procedure that disables the agent record and blocks new tokens from being issued. Existing tokens remain valid until they expire unless separately revoked. There's no automatic behavioral trigger yet that would, for example, kill an agent's session mid-task because it started doing something it shouldn't.
Why this matters beyond Okta's customer base
None of this is a knock on the launch. Replacing standing static keys with short-lived, identity-governed tokens closes a real and commonly exploited gap, and doing it as a default inside a product already running at 20,000+ organizations is a meaningfully bigger lever than a standalone point solution would be. Cross App Access being a genuinely open, OAuth-extending protocol (and an official MCP authorization extension) also means the identity model isn't a walled garden other vendors have to reverse-engineer.
But "an agent has a scoped, short-lived token" and "an agent is behaving safely inside the scope that token grants" are two different claims. Identity answers who is allowed to knock on which doors. It says nothing about what the agent does once it's inside the room: whether it can be prompt-injected into misusing a legitimate, correctly-scoped permission, whether it drifts from its assigned task, or whether it starts coordinating with other agents in ways nobody authorized. That's a runtime behavior problem, and it sits on top of identity infrastructure, not inside it.
If you're rolling out Agent SSO or a comparable identity layer, pair it with actual adversarial testing of what your agents do once they're authenticated. Identity is necessary. It isn't sufficient.
pip install humanbound
Point it at your agent stack and see what it does with the access it's been correctly granted.
References and sources
- Okta newsroom: Okta brings first-class identity to AI agents with Agent SSO
- Okta: AI Agents at Work 2026 report
- Okta: Understanding the Okta for AI Agents kill switch
- TechNode Global: Okta launches Agent SSO for governing enterprise AI agents
- Quasa: Okta Agent SSO Replaces Static Keys, but It Does Not Govern Every Agent
- SecurityBrief Australia: Okta launches Agent SSO to manage enterprise AI agent access
