On 24 August 2026, Okta made Agent SSO generally available, giving AI agents first-class identities in Universal Directory and replacing static API keys with short-lived, policy-governed tokens. It is the most useful piece of agent security infrastructure shipped this year, it is included in core Okta SSO plans at no additional cost, and security teams should turn it on. It also carries a precondition most enterprises cannot currently meet: an agent has to be registered before identity can govern it.
That precondition is where this week's news collides with this month's data. Akamai's Enterprise AI Usage Risk Report 2026 found that 47.11% of enterprise AI conversations take place through personal identities rather than corporate accounts. Those conversations never reach an identity provider at all. They are not agents waiting to be issued tokens — they are employees with browser tabs. Two different control planes are involved, and this week only one of them moved.
Agent identity finally has a standard worth adopting
The substance of the Okta release is the standard underneath it. Agent SSO is built on Cross App Access, a vendor-neutral protocol that extends OAuth and has been incorporated as the official Enterprise-Managed Authorization extension for the Model Context Protocol. An agent is registered in Universal Directory, administrators apply the access policies they already use for employees, and the agent receives short-lived tokens when it needs to act on a user's behalf. Ric Smith, Okta's President of Products and Technology, framed the problem accurately: granting agents access to enterprise systems "shouldn't require trading away security or visibility."
The credential pattern this replaces deserves the criticism it gets. Static API keys are long-lived, over-scoped, copied into configuration files and CI variables, shared between services, and effectively invisible to revocation workflows. Swapping them for short-lived tokens tied to a named identity is a genuine reduction in blast radius. Okta's own research found that only 34% of organisations apply the same security controls to AI agents as they do to human workers, so the baseline being improved on is low. That the protocol is open matters more than the product: it means the control survives a change of identity vendor.
What does Okta Agent SSO actually govern?
Agent SSO governs supported agent-to-application connections for agents that implement Cross App Access. It registers those agents in Okta's Universal Directory, applies the same access policies administrators already use for employees, and issues short-lived tokens scoped to acting on a specific user's behalf. Replacing static API keys is the single most valuable thing it does. What it does not do is equally important. Agent SSO is not a discovery mechanism: an agent becomes visible after it has been registered or connected, so it is not an inventory of every autonomous process running in your environment. It does not cover agents that lack Cross App Access support, agent-to-agent connections, or runtime enforcement of what an agent does once it has been authorised. Discovery, certification reviews, approval workflows and deactivation sit in the separate Okta for AI Agents subscription. Okta is explicit about this split, and buyers should read it carefully.
Is Cross App Access the same thing as MCP?
No, but they are now formally connected. The Model Context Protocol is the open standard for how an AI application connects to tools and data sources. It defines the plumbing, not the permission model, which is why early MCP deployments leaned on static API keys and long-lived personal tokens. Cross App Access extends OAuth to answer the authorisation question instead: which agent, acting for which user, may reach which resource, and for how long. It has been incorporated as the official Enterprise-Managed Authorization extension for MCP, which means the two are designed to be used together rather than as competitors. For security teams the practical reading is straightforward: if your organisation is deploying MCP servers, Cross App Access is the mechanism that lets you stop handing them static credentials. It is vendor-neutral, so adopting it does not lock you to a single identity provider.
Identity governance starts at registration. Discovery is what fills it.
Every identity-based control inherits the completeness of the inventory beneath it. You cannot issue a short-lived token to an agent you have never seen, apply policy to a connection that never requests one, or revoke access that was never granted through you. This is not a flaw in Agent SSO. It is a structural property that single sign-on has always had.
The precedent is shadow SaaS. Enterprises adopted SSO broadly over the last decade and still ended up with hundreds of unfederated applications, because SSO governs the apps you federate, not the apps a team signs up for with a corporate card. Shadow AI is the same failure mode running considerably faster, with a lower barrier to entry and no procurement step at all. Google Cloud made a related point on the same day, describing agents as "the ultimate insiders" and reporting that 79% of technology leaders name security, governance or operations as their biggest barrier to scaling AI.
Why doesn't agent identity solve shadow AI?
Because most shadow AI is not an agent. It is a person. When an employee opens a personal ChatGPT account in a browser tab and pastes a customer list into it, there is no agent to register, no token to issue and no connection request for an identity provider to evaluate. Akamai's telemetry puts 47.11% of enterprise AI conversations in exactly that category. Identity controls act at the moment something asks for access to a system you own. Shadow AI usually does the opposite: it takes data out of a system the employee is already legitimately logged into, and sends it somewhere you do not own. The authorisation decision has already succeeded. Agent identity closes a real and serious gap for machine actors, but it operates one layer above the place where most enterprise AI data loss actually happens.
Nearly half of enterprise AI use never reaches the identity plane
Akamai's report is built on real-world usage telemetry rather than survey responses, which makes its numbers worth more than the usual adoption statistics. Alongside the 47.11% figure, it found that more than 14% of enterprise AI conversations involved personal "freemium" AI subscriptions attached to corporate email addresses. That combination is the worst of both worlds: it carries the organisation's domain, so it looks governed in a spreadsheet, while the account, its data retention terms and its access controls sit entirely outside the organisation's control.
The exposure is also concentrated. Akamai found that the top 5% of users generate at least 144 conversations each, often exceeding 18 prompts per conversation, while half the workforce barely engages at all. Or Eshed, Akamai's VP of Enterprise Security, described the shift plainly:
AI is no longer just a productivity booster; it is a collaborative colleague with direct access to the corporate crown jewels.
Concentration is operationally good news. It means the highest-value intervention is a targeted programme aimed at a few hundred people, not an organisation-wide campaign that takes a year and annoys everyone.
The browser extension layer is the least governed software you install
Akamai found that nearly 75% of AI browser extensions request high or critical permissions, and that 16.3% contain known CVEs. Extensions run inside the authenticated session. They can read the rendered contents of your CRM, your email client and your ticketing system after single sign-on has already succeeded — which is precisely the point at which an identity decision has finished and stopped protecting anything.
The three AI-native attack techniques Akamai names for 2026 all live at that layer. Vibe hacking manipulates local instruction files so a coding assistant produces insecure output or takes unauthorised action. CursorJacking harvests API keys through a rogue extension. CometJacking uses indirect prompt injection to exfiltrate data through an AI browser. None of these are defeated by a better token, because in every case the authorisation was legitimate and the abuse happened afterwards.
Govern two planes, not one
The practical model is two planes with different controls. The first is the machine identity plane: agents that connect to systems, governed by registration, short-lived tokens and least privilege. Agent SSO is now a good answer here and should be adopted. The second is the interaction layer: what people and agents actually send — prompts, pasted text, uploaded files, extension traffic — regardless of which identity, if any, is attached. Nothing on the identity plane inspects content, and content is where the data loss occurs.
- Build an observed inventory of AI use, not a surveyed one. Discovery has to run in the browser and on the endpoint, because personal-identity sessions never touch your identity provider.
- Enable Agent SSO for every agent that supports Cross App Access. It is included in core Okta SSO plans, so the only real cost is configuration time.
- Start with the top 5% of users. Concentration means a targeted programme captures most of the exposure for a fraction of the effort.
- Treat AI browser extensions as privileged software: inventory them, review the permissions they request, and allowlist rather than blocklist.
- Inspect the interaction layer with contextual DLP that reads prompt and upload content, not just endpoints, email and file shares.
- Close the corporate-email-on-personal-subscription path. It looks governed and is not.
How do you discover AI use that has no corporate identity?
You observe it where it happens, which is the browser and the endpoint. Sessions authenticated with personal credentials never appear in identity provider logs, so an IdP-based inventory is structurally blind to them. Three signals actually work: browser telemetry that sees which AI applications an employee opens and what they submit; endpoint inspection of traffic to AI providers, including native desktop applications that bypass the browser entirely; and egress analysis matched against a maintained catalogue of AI service domains. The catalogue is the part teams underestimate. Akamai describes a long tail of unmanaged applications running beneath the handful of platforms security teams actually watch, so a control that recognises the top twenty providers and nothing else simply recreates the visibility gap at a smaller scale. Discovery also has to be continuous, because the AI tool market turns over fast enough that a point-in-time audit is stale within a quarter.
What should a CISO do in the first 30 days?
Start with measurement, not policy. Most AI acceptable-use policies fail because they are written against an imagined usage pattern rather than the real one. Spend the first two weeks establishing an observed inventory: which AI applications are in use, by whom, through corporate or personal identities, and what categories of data are being submitted. Then act on concentration, because Akamai found the top 5% of users generate at least 144 conversations each. In parallel, two changes cost almost nothing: enable Agent SSO for every agent that supports Cross App Access, since it is included in core Okta SSO plans, and audit AI browser extensions as privileged software, given that nearly 75% request high or critical permissions. Only then should you write or revise the policy, because by that point you will be governing what people actually do.
Agent SSO is a real advance and the open standard beneath it is the right long-term bet. But it governs the agents you have registered, and this week's data says nearly half of enterprise AI use never registers anywhere. The identity plane moved forward. The interaction layer did not.
How Aona closes the interaction-layer gap
Aona is a Workforce AI Security platform built for the plane identity cannot reach. It discovers AI use across more than 10,000 tools from the browser and the endpoint — including personal-account sessions that never touch your identity provider — shows you who the high-volume users are, and enforces real-time data protection on what is actually being sent, with file redaction for DOCX, Excel and PDF uploads. See how Aona discovers and governs Shadow AI.
