Agent identity vs. agent control

In 2026 the identity providers arrived at agents. Okta shipped Okta for AI Agents (discover, register, and revoke agents), then Agent Gateway and Agent-to-Agent Connections (validate an agent and the user behind it, broker a short-lived credential at runtime), then made Agent SSO part of its core SSO plans. Auth0’s Auth for GenAI does the equivalent for product builders. Entra is on the same road.

This is good news, and not just for Okta. Agents holding long-lived shared service credentials was an obvious hole, and the identity plane is the right layer to fix it. If your organization runs Okta, use these products.

It’s also worth being precise about what they do — because the announcements and the incident data describe two different problems.

What the identity plane decides

Every product in this wave operates at connection and credential time. Agent SSO gives an agent a first-class identity when it connects. Agent Gateway checks the policies attached to that agent and mints a short-lived, scoped credential. Resource Access Certifications periodically review whether the agent should keep its access. Revocation cuts the agent off.

Each of these answers a form of the same question: should this agent hold this credential? Who is it, who’s behind it, what scopes does it get, does it still deserve them, can we shut it off.

What none of them examine is the tool call itself. The credential is minted before the action exists. A scoped token that permits crm.write permits every write it will ever be used for — the routine update and the prompt-injected mass delete look identical at the credential layer, because at that layer they are identical: same agent, same user, same valid token, same scope.

Where the incidents actually happen

Okta’s own launch research says 88% of organizations report suspected or confirmed AI agent security incidents. Walk through the recurring failure classes and note what credential state each one runs in:

Failure	Credential state	Visible at connection time?
Prompt injection steers the agent to exfiltrate or destroy data	Valid, in scope	No — the token was granted before the injected content existed
Agent takes an over-broad action inside a granted scope (wrong recipient, wrong table, `--force`)	Valid, in scope	No — scope granularity is per-resource, not per-action
Runaway loop re-issues the same expensive or destructive call	Valid, in scope	No — the 400th call carries the same credential as the 1st
Confused deputy: agent’s blanket permissions exceed the initiating user’s	Addressed — this is the identity plane’s home turf	Yes, if user context flows through
Rogue or forgotten agent still holding access	Addressed — discovery, certification, revocation	Yes

The last two rows are real, and the identity products handle them. The first three are where agents differ from every workload identity systems were built for: the entity behind the credential is non-deterministic and steerable by its own input. The credential can be perfectly scoped and the action still wrong. Revocation helps after you’ve noticed — and noticing requires a record of actions, which a system that logs authentications and token grants doesn’t have.

What the control plane decides

An Agentic Control Plane sits one layer later, on the runtime call path. Its unit of decision is the individual tool call: this tool, these arguments, this session’s history. For each one it decides allow, ask a human, or deny — and logs the decision with its reason.

That position is what makes the failure classes above tractable:

The prompt-injected destructive call is a different tool call than the routine one — different tool, different arguments. A per-call policy can treat them differently; a credential can’t.
An ask puts a human in front of the specific action, not in front of a scope grant. An approval can become a standing rule, so the friction decays instead of accumulating.
The audit trail is a record of actions and decisions — what the agent did and why it was allowed — not a record of logins. When something goes wrong, this is the artifact that answers “what happened,” and it’s the evidence that makes revocation timely instead of forensic.

And to be equally precise in the other direction, here’s what a control plane is not: it’s not an IdP. It doesn’t manage your workforce directory, run SSO for your applications, certify access across your SaaS estate, or discover shadow agents in departments that never touched it. If you need an inventory of every agent in a 10,000-person enterprise, that’s Okta’s product, not this one.

They compose — at the credential seam

The two layers meet cleanly, because they already speak the same protocol. ACP verifies RS256 JWTs from any OIDC provider — Okta, Auth0, Entra ID, Keycloak, anything with a JWKS endpoint. An identity minted by your IdP arrives at the control plane as the verified principal, and every per-call decision and audit row is attributed to it: this user, through this agent, attempted this action, and here’s what the policy said.

IdP (Okta / Auth0 / Entra)          Control plane (ACP)
─────────────────────────           ─────────────────────────
who is this agent?                  should this call run?
who is the user behind it?          allow / ask / deny, per call
what scopes does it get?            evaluated on tool + arguments
short-lived credential, minted      decision logged with reason
        │                                   ▲
        └──── verified JWT ─────────────────┘
              flows into every call

One issues the badge. The other watches the hands. Neither does the other’s job, and an agent handling anything that matters wants both.

The question to ask your stack

If you’re evaluating this space, one question separates the layers faster than any feature list: “Show me the record of what the agent did yesterday — every action, and why each one was allowed.”

An identity product answers with authentications, token grants, and connections. A control plane answers with tool calls, arguments, and decisions. If the incident you’re worried about is an agent that shouldn’t have access, the first answer is the one you need. If it’s an agent with access doing the wrong thing — the 88% case — it’s the second.

Does Okta for AI Agents replace an agentic control plane?

No — it operates one layer earlier. Okta’s agent products (Agent SSO, Agent Gateway, Agent-to-Agent Connections) establish who an agent is, validate the user behind it, and broker short-lived credentials at connection time. A control plane decides whether each individual tool call should run — allow, ask a human, or deny, based on the tool, its arguments, and session context — and records the decision. Identity answers ‘should this agent hold this credential.’ Control answers ‘should this agent take this action, right now.’

Can I use Okta and an Agentic Control Plane together?

Yes, and that’s the intended shape. ACP verifies RS256 JWTs from any OIDC provider — Okta, Auth0, Entra ID, Keycloak — so an Okta-issued identity flows into the control plane as the verified principal on every tool call. The identity plane establishes who; the control plane enforces what, per call, and writes the audit trail of actions rather than logins.

If an agent only has scoped, short-lived credentials, why does it still need per-call control?

Because the damaging failures happen inside legitimately granted scope. A prompt-injected agent deleting the wrong records, an over-broad write, a runaway loop re-issuing the same call — all of these use valid credentials doing exactly what the scope permits. Scopes are decided at grant time, before anyone knows what the agent will actually attempt. Per-call control evaluates the action itself, at the moment it’s attempted.

What about Auth0's Auth for GenAI and asynchronous authorization — isn't that human-in-the-loop?

It’s the closest thing to it in the identity world: a human approves before a token is released to the agent. But the approval gates token issuance for a scope, not a classified action — once the token is out, every call it enables runs unexamined. A control plane’s ask decision happens per tool call, sees the tool name and arguments, and can turn an approval into a standing rule.