# Agent identity vs. agent control: what Okta for AI Agents does — and what it can't see

Okta, Auth0, and Entra now issue identities and credentials to AI agents. That solves who the agent is. It doesn't decide whether a specific tool call should run. Here's where the identity plane ends, where the control plane begins, and how the two compose.

# Agent identity vs. agent control

In 2026 the identity providers arrived at agents. Okta shipped [Okta for AI Agents](https://www.okta.com/newsroom/press-releases/showcase-2026/) (discover, register, and revoke agents), then [Agent Gateway and Agent-to-Agent Connections](https://www.okta.com/newsroom/articles/okta-july-2026-product-innovations/) (validate an agent and the user behind it, broker a short-lived credential at runtime), then made [Agent SSO](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-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](https://www.okta.com/newsroom/articles/ai-agents-at-work-2026-agentic-enterprise-security/). 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](/what-is-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](/what-is-runtime-authorization), 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](/agent-identity) — 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.



---

*Related: [The three planes of running agents](/three-planes) · [What is an Agentic Control Plane?](/what-is-an-agentic-control-plane) · [Agent identity in ACP](/agent-identity) · [What an ACP is not](/comparison) · [What is runtime authorization?](/what-is-runtime-authorization)*