A Compromised Agent Doesn't Steal an Identity. It Borrows One That's Already Trusted.

What Agent SSO actually does

Okta shipped Agent SSO this year, and it's worth describing plainly before getting to the point of this post, because it's genuinely useful infrastructure. It registers AI agents that support Cross App Access as first-class identities in Okta's Universal Directory — the same place your employees live. It replaces the static API keys and one-off OAuth grants agents have been running on with short-lived, identity-governed tokens. Administrators manage agent access through the same console and workflows they already use for people. At Oktane 2026, Okta broadened this into an "identity security fabric" — agent discovery, access governance, behavioural analytics, verifiable credentials — unifying human, machine, and agent identity under one system.

None of this is a strawman. It's the right move, and enterprises adopting agents at any scale need exactly this kind of infrastructure.

What Okta's own materials say it doesn't do

Here's the part worth reading closely. Okta's own product page for Agent SSO lists, plainly, what it does not cover: runtime inspection or monitoring of agent behaviour, and governance of what an agent actually does once it's connected. The broader "Okta for AI Agents" tier — detect, discover, authorise, govern — carries the same boundary. An earlier blueprint framed three questions: where are my agents, what can they connect to, what can they do. That third question turns out to mean authorisation of individual tool calls and logging of what happened, not inline inspection of what a call actually contains or returns.

This isn't a gap being inferred from outside. It's a line in Okta's own documentation.

Identity answers who. Not what happens after.

Identity answers one question: is this connection who it claims to be. It doesn't answer the next one: what does it do once it's in. A fully authenticated agent, correctly authorised under Agent SSO, can still be handed a tool that changed its declared behaviour after approval, or a package that stayed clean for fifteen versions and wasn't on the sixteenth. Identity checks pass in both cases — cleanly, correctly, exactly as designed — because that was never what identity was checking.

SiliconANGLE's Oktane coverage quoted Krista Case of theCUBE Research putting it well: agents turn identity from an access problem into an execution problem. Okta's own numbers show why this matters at scale — their May 2026 research found 92% of organisations already have agents in widespread or moderate use, and only 34% apply the same security controls to them as to human staff.

The gap this blog has already shown twice

This isn't hypothetical. The postmark-mcp backdoor covered on this blog was a properly installed, properly named package — nothing about the connection was illegitimate. Invariant Labs' rug-pull research showed a tool whose definition changed after it had already been approved, with no re-authorisation step to catch it. Neither case involved a stolen or spoofed identity. Both involved a trusted connection doing something its identity checks had no way to see.

That's the whole thesis, restated plainly: a compromised agent doesn't need to steal an identity. It already has one that's trusted. Identity systems have no visibility into what it does with it.

CheckedAgent picks up exactly where identity leaves off — not who an agent is, but what it does once it's already trusted.

Frequently asked questions

Does this mean Okta's Agent SSO is inadequate?
No. It solves a real problem — agents running on static credentials with no owner or audit trail — and solves it well. It was never designed to inspect runtime behaviour, and Okta says so in its own materials.

Is CheckedAgent an identity provider?
No. CheckedAgent doesn't manage who an agent is or what it's authorised to connect to — that's Okta's and Auth0's job. CheckedAgent inspects what happens over a connection once it's already been authorised.

What's the actual security gap here?
Identity and access management confirm a connection is legitimate at the point of authorisation. They don't continuously inspect the content of what's sent and returned over that connection afterwards — which is where both the postmark backdoor and the MCP rug pull actually happened.

Where do these adoption figures come from?
Okta's own "AI Agents at Work 2026" report, published 27 May 2026: 92% of organisations report agents in widespread or moderate use; only 34% apply the same security controls to agents as to human staff.