Okta Just Validated a $12B Market — and Revealed the Gap They Can’t Fill

Written by Mark Rogge, CEO & Founder, EnforceAuth

Okta reported $876M in Q4 FY2026 revenue last month. That's 11% year-over-year growth. A $4.6B ARR machine, still accelerating, and a CEO who staked the entire earnings call on a single word: AI.

I've spent my career at the intersection of enterprise security and policy. Styra, OPA, GitLab, Weights & Biases. I've watched market categories form in real time, watched incumbents stretch into adjacencies they weren't built for, watched the exact moment a platform's architecture hits a wall it can't engineer around.

This is one of those moments.

Here's the part the market hasn't fully priced in: Okta's announcements validate the problem. They don't solve it. And the distinction between those two things is worth billions.

The Signal Buried in the Revenue Headline

Beneath the topline number sits a data point that should stop every CISO cold. It comes from Okta's own research (The State of AI in the Enterprise, 2026): 89% of enterprises are deploying AI agents. Only 10% have adequate governance over what those agents do.

Read that again. Nine out of ten enterprises running agents. One in ten actually governing them.

So what was Okta's response? They launched several new products. Cross App Access, or XAA, is the headliner, a new open protocol extending OAuth for agent-to-app interactions, backed by AWS, Salesforce, Google Cloud, and Box. They also shipped Okta for AI Agents and new Auth0 AI integrations.

These are real investments, and XAA in particular deserves credit. Replacing static API keys with short-lived, scoped tokens for agent sessions is genuinely valuable work. It establishes trusted agent identities at session start, validates credentials, issues scoped tokens. Good stuff.

But XAA enforces at the door.

What happens after the door? That's exactly where the problem lives.

Why Is Authentication Not the Same as Authorization?

Look, the market hasn't internalized this distinction yet. And it's the one that matters most.

Authentication asks: who are you? Okta owns this completely. Login, MFA, SSO, credential management, token issuance, agent registration. XAA is a genuine advance in establishing trusted, scoped agent identities at session start. No argument there.

But authorization asks something different entirely. What are you allowed to do, right now, in this specific context? Not what you were allowed to do when the token was issued. What you're allowed to do at this moment, for this action, against this resource, given everything that's changed since you authenticated.

They're sequential layers of the same security stack. Okta governs layer one brilliantly. Layer two? Ungoverned. We call that gap between token issuance and runtime enforcement the Authorization Gap.

The Breach XAA Can't Prevent

Walk through this with me. An AI agent authenticates through XAA. Token issued. Identity verified. Scoped credentials granted. Everything in the governed zone works flawlessly.

Now the agent starts operating. It makes API calls, accesses data, invokes tools, chains actions together. And somewhere in that sequence, it touches customer PII that falls outside its operational need. Maybe the token scope was broader than the task required. Maybe the data classification changed after issuance. Or maybe the agent's behavior shifted mid-session in ways nobody anticipated when the policy was written.

Every authentication check resolves perfectly. The breach exists entirely within valid token scope. It is invisible to any authentication platform, because the platform's job ended when the token was issued.

Continuous runtime enforcement is the only architecture that catches this. Not authentication at session start. Authorization evaluated at every action, in real time, across every domain.

Why the Trust-Once Model Breaks Down

Okta's trust model was designed for an era when authentication was the primary control. Verify the identity at login, then trust from there. That architecture served the human-use era well enough. Humans are slow. They click through workflows one at a time. They take lunch breaks. And a human in the loop provides an implicit sanity check that keeps the blast radius limited.

AI agents don't work that way.

A single agent can execute thousands of autonomous actions per session. Against live data. No human reviewing each step. So the gap between "who is this" and "what is it doing right now" stretches from seconds to hours, and the number of decisions in that window goes from dozens to tens of thousands.

Closing the Authorization Gap requires continuous identity. Not authentication once at session start, but authorization evaluated at every action. Every API call checked against current policy, not the token scope from twenty minutes ago. Every tool invocation evaluated against attribute-based constraints, not just role membership. If a sensitivity threshold gets crossed or a risk score spikes on the underlying identity, enforcement responds instantly. It doesn't wait for the next authentication event.

What Four Authorization Domains Does Okta Miss?

Point is, the Authorization Gap isn't a single problem. It spans four operational domains where AI agents work, and where Okta has no enforcement presence.

Applications

Fine-grained, attribute-based access control at every API call. Not just "can this agent call this endpoint" but "can this agent, with this context, access this specific resource, given current policy." Evaluated per request, not per session. Okta's token tells you the agent is who it says it is. It doesn't tell you whether this particular action, against this particular data, should be allowed right now.

Infrastructure

Why doesn't Okta cover infrastructure? Because their architecture was never built for it. Policy-as-code for cloud operations, resource admission control, IAM privilege escalation prevention, IaC guardrails. AI agents increasingly interact with cloud infrastructure directly, spinning up resources, modifying configurations, deploying code. None of that falls within Okta's enforcement surface.

Data

An agent might have a valid token granting access to a database. That doesn't mean it should see every row. Row-level, column-level, and attribute-level enforcement at query time is a separate surface entirely, one that prevents agents from over-accessing data even when the application layer permits it. Okta has no capability here.

AI Workloads

And then there's the domain that didn't exist before agents. Runtime action enforcement for tool calls, chained actions, rate limits, time-of-day policies, all continuously re-evaluated throughout the session. An agent authorized to call a specific tool at 2 PM might not be authorized at 2:15 PM if the context shifted. No authentication platform can govern this.

No incumbent covers all four domains continuously. Point solutions handle one layer, sometimes two. EnforceAuth provides unified authorization across all four in a single platform, with continuous identity verification for both human and non-human identities.

Authorization Coverage by Platform

What This Means for CISOs

Here's the thing about Okta's earnings: they reveal something beyond revenue. In the most direct economic sense, they represent market development for the authorization enforcement category. Every CISO briefed by Okta on agentic AI governance is receiving the first half of a conversation that ends somewhere very different.

Identifying your agents? That question is being answered. Okta's working on it. Others are too.

But what governs what those agents actually do after they authenticate? For nearly every enterprise today, the answer is nothing. Token scope and maybe some content filters. That's the Authorization Gap, and it's sitting wide open in production environments right now.

The Question to Ask Your Team This Week

Skip the identity strategy discussion for a moment. Your team probably has that covered, or Okta is helping you cover it. Instead, ask this: for every AI agent we have in production, what enforces what it's allowed to do after it authenticates? If the answer involves the words "token scope" and stops there, you've got work to do.

What This Means for the Market

I've seen this pattern before. The market leader spends considerable capital educating buyers that a problem is real. Enterprise budgets start forming around that problem. Then it becomes clear that the incumbent's architecture can't solve the full scope of what they just convinced everyone matters.

Historically, the window between category creation and consolidation is 18 to 36 months. Okta's Q4 earnings started that clock.

Agentic AI didn't create a security problem. It revealed one that was always there. Fine-grained authorization, continuously enforced at runtime across every layer, was never solved. It is the hardest problem in enterprise security. AI just made it impossible to keep deferring.

One company will capture the identity lifecycle layer. Okta's well-positioned for that, and their investments confirm it. But the authorization enforcement layer, the runtime, continuous, multi-domain piece, sits structurally outside what their architecture can deliver.

Common Questions About Enterprise Authorization

What is the Authorization Gap?

The Authorization Gap is the space between authenticating an identity (human or machine) and governing what that identity actually does at runtime. Most enterprises have strong authentication through providers like Okta or Entra ID, but almost none enforce fine-grained, continuous authorization over the actions taken after login. For AI agents executing thousands of autonomous actions per session, this gap represents the primary unaddressed attack surface.

Does Okta's XAA protocol close the Authorization Gap?

XAA is a genuine advance for agent identity and session establishment. It replaces static API keys with scoped, short-lived tokens, which is valuable work. But XAA enforces at session start, not at runtime. Once the token is issued, there is no continuous evaluation of whether each subsequent action should be allowed given current context, data sensitivity, or behavioral drift. The Authorization Gap exists after the door, not at it.

What does continuous runtime enforcement mean?

Continuous runtime enforcement evaluates every action an agent takes, not just the initial authentication event. Each API call, tool invocation, data access, and chained action is checked against current policy in real time, accounting for factors like resource sensitivity, delegation chains, time-of-day constraints, and behavioral anomalies. If conditions change mid-session, enforcement adapts instantly rather than waiting for the next authentication event.

How do AI agents differ from humans for access control?

Humans are slow, sequential, and self-limiting. They click through one workflow at a time and provide an implicit sanity check on their own actions. AI agents execute thousands of autonomous actions per session against live data with no human reviewing each step. They chain actions across system boundaries, inherit broad credentials, and can shift behavior mid-session in ways no one anticipated when the policy was written. Traditional role-based access control was designed for the human pattern and breaks down entirely at agent speed and scale.

The market leader just told you the problem is real. We built the solution they can't.

If you're running agents without authorization controls, we should talk.