Okta Got It Right. Now Comes the Hard Part.

Okta was right.

Okta and Anthropic announced three things: ISPM for Claude Enterprise, Okta for AI Agents, and an MCP Bridge bringing Claude Code into the identity perimeter. The important signal was not any single feature. It was the category claim: AI agent security is now an identity problem.

Okta is right about the category. Okta is right that this is now an identity problem. The question worth examining — and the one Okta’s announcement does not answer — is whether identity is the same thing as authority at the moment of action. It is not.

What Okta Shipped (and Got Right)

Okta ISPM + Claude Compliance API is real value. Posture monitoring — stale API keys, offboarding gaps, dormant accounts — is exactly what Okta does well for every other SaaS application in the enterprise. Extending that to Claude is straightforward and necessary. Every Claude deployment should have it.

Okta for AI Agents normalizes AI agents as identity objects inside the identity provider. Each agent gets a registered identity, a scoped token, and a defined lifecycle. That is meaningfully better than the current alternative — service accounts shared across half a dozen automations with no owner and no expiry. If you have AI agents in production today, formalizing their identity at the IdP is a step forward.

The MCP Bridge brings Claude Code into the identity perimeter via a professional services engagement. The fact that Okta sees the MCP layer as the new control surface — and is willing to staff integrations to land it there — signals the right priority for an enterprise IdP in 2026.

The framing matters most. Six months ago, “AI agent governance” was a marketing label slapped on whatever a vendor already shipped. Today, the largest cloud IdP is saying the quiet part out loud: this is an identity problem, and it needs identity infrastructure to solve.

Okta is in. The market has been validated. Now look at what shipped — and what did not.

What’s Missing — Authority Governance

What Okta for AI Agents actually ships is identity at the perimeter. Token scoping. Lifecycle governance. Each agent gets a credential with permissions attached at issuance time. That is service accounts with new labels — a meaningful upgrade over today’s identity sprawl, but the enforcement model is fundamentally the same: the credential carries the authority, and the credential is checked at the door.

(We documented this exact pattern in Boulevard of Broken Dreams. The receipt has a line item for it.)

The MCP Bridge is the tell. Okta is right that MCP is becoming the new enterprise control surface. But a bridge is still an integration pattern: professional services connecting Claude Code to the identity perimeter. That is useful, but it is not the same thing as an MCP layer that understands persona, scope, delegation, runtime guidance, and decision proof. We wrote about this distinction in Not All MCPs Are Created Equal: wrapping tools is table stakes; governing autonomous operators is the hard part.

Here are five questions Okta’s announcement does not answer:

1. Who delegated this authority to the agent, and at what scope? Token issuance is not delegation provenance. An agent with a scoped token does not carry a record of who granted what authority on whose behalf.
2. Is the agent’s scope enforced at the moment of action, or only at token check? Tokens are stateless artifacts; runtime scope — what this agent is allowed to do, against this resource, right now — is stateful and changes faster than tokens rotate.
3. Can the agent act on resources its delegating principal could not? Scope inheritance vs override is a runtime authorization problem, not a perimeter problem.
4. Where is the audit-grade decision trace that proves the agent stayed within scope? An action log records what happened. A decision trace records why it happened — the distinction the EU AI Act is built around.
5. Can a regional manager delegate authority to an agent without involving the platform team? Self-service delegation is the original portal problem, recurring at agent scale.

Each of these is a runtime question, not a perimeter question. They live below the layer Okta operates at. Authority Governance is the runtime layer that computes, enforces, and audits delegated authority at the moment of action — and it is what IdentityRM ships.

Perimeter and Authority

Okta brings agents into the identity perimeter. IdentityRM gives them governed authority: context before action, enforcement during action, and proof after action. Both matter. Neither is the other.

An enterprise running Okta for AI Agents and Authority Governance together has both necessary layers represented. The perimeter is monitored, the credentials are scoped, the lifecycle is managed — and at the moment of action, the agent’s authority is computed against a stateful delegation model, enforced structurally, and logged with audit-grade decision provenance. That is the complete picture.

An enterprise running Okta alone has the perimeter problem solved. The runtime delegation question stays open. The custom admin portal you would have built in 2018 to fake delegation for human operators is the same shape as the bespoke kernel logic you would write in 2026 to fake delegation for agents. The boulevard now has corporate sponsors. The runtime layer is still missing.

IdentityRM ships Authority Governance as the runtime layer that fits alongside Okta — for human operators, AI agents, IdP and non-IdP systems alike. Built on US Patent 12,549,558. New here? Start with what Authority Governance actually is, or see how the platform works.