What Identity Means When It Works
In IDAM, "identity" is a solved problem in the sense that the field has agreed on what the question means and how to answer it. A principal — a human user, a service account, a device — has attributes. Those attributes are bound to a credential. The credential is issued by an authority the relying party trusts. Policy governs what the principal can do, and every access decision traces back to that chain: credential, attributes, policy, decision.
Okta resolves a principal by validating a credential against a directory, enriching the token with attributes from the appropriate sources, and handing the relying party something it can make an authorization decision against. PAM handles the privileged end of this — vaulting credentials, enforcing just-in-time access, recording session activity so the audit trail is complete. Federation carries identity claims across trust boundaries using protocols that both sides have agreed to honor. The whole architecture assumes a principal that exists before the session starts, has a credential that can be validated, and will be the same principal throughout the interaction.
That assumption is doing a lot of work. You don't notice it until it breaks.
Where the Analogy Stops
Agentic AI systems break the assumption in four specific ways, and it's worth naming them precisely because each one maps to a different place where your IDAM intuition will generate a wrong answer.
The credential anchor problem. In IDAM, identity is bound to a credential — a certificate, a client secret, an OAuth token with a verifiable issuer. An AI agent's "identity," in most current implementations, is a combination of its model version, its system prompt, its deployment configuration, and the API key it was given at startup. None of these are credentials in the PKI or OAuth sense. The model version isn't signed by an authority the relying party trusts. The system prompt can be modified. The API key authenticates the deployment, not the agent's specific instantiation or its current behavioral state. When a CAIO asks "who is this agent?", the honest answer in most current architectures is: a process running under a service account, with no cryptographic binding between that service account and the agent's actual decision-making logic.
The delegation depth problem. OAuth has delegation. The on-behalf-of flow, token exchange, the whole RFC 8693 apparatus — these exist precisely because humans sometimes need to authorize services to act for them. But OAuth's delegation model assumes a human at the top of the chain who made an explicit authorization decision. Agentic systems can spawn sub-agents dynamically, mid-task, without a human authorization event at each step. The orchestrator decides it needs a research sub-agent and a code execution sub-agent, and those sub-agents inherit some scope of the orchestrator's permissions. Where was the authorization decision? When the human kicked off the original task. Does that authorization cover what the sub-agents are actually doing three steps later? The architecture doesn't have a clean answer, and neither does the governance framework.
The session boundary problem. IDAM sessions have defined lifetimes. They start with an authentication event, they end with a timeout or explicit logout, and re-authentication is required when the session expires. An agent task doesn't map cleanly onto a session. A complex agentic workflow might complete in thirty seconds across what would be dozens of logical context switches, or it might persist for hours across what would be multiple human session lifetimes. The re-authentication trigger — the event that says "we need to verify this principal again" — doesn't have an obvious analog in an agent that's been running continuously, accumulating context, and making decisions the whole time.
The audit chain problem. In IDAM, "who did this?" traces to a credential, which traces to an identity, which traces to an authorization decision made by a human or a policy engine. In an agentic system, the chain traces to a model inference. The agent called the API because its reasoning process, given its context window at that moment, determined that was the right action. That is not an authorization decision in any governance sense your compliance team will recognize. The action happened. The credential that authorized it was valid. But the decision to take the action lives inside a model, not inside a policy engine, and it cannot be audited the way a policy decision can.
The Field Is Actively Arguing About This
If you're reading this thinking "surely someone has solved this," the honest answer is: people are working on it, and the working is public, and it's not done.
The OWASP Agentic Security Initiative, launched in 2025, has been developing threat models specifically for agentic architectures — the published drafts treat agent identity as an open problem, not a solved one. The Coalition for Secure AI (CoSAI), which includes major cloud providers and security vendors, has a workstream explicitly focused on AI agent governance that has published preliminary frameworks but no settled standards. The arXiv literature on agentic security — papers from research groups at major institutions — consistently identifies identity and authorization as the least-solved layer of the agentic security stack.
The standards bodies are moving. The IETF and OAuth working groups have discussions underway about extending existing authorization frameworks to cover non-human principals with dynamic delegation chains. But "discussions underway" is not "deployed and interoperable," and the gap between those two states is measured in years, not quarters.
A CAIO asking about agent identity governance has been reading the same literature. They know the field is unsettled. They're not asking you to solve it — they're asking whether you understand the problem well enough to be a useful partner in navigating it. The seller who responds with a clean answer will be identified as someone who hasn't done the reading.
What Okta Has, and What It Doesn't
Okta has been public about where it's placing its bets on the agent identity problem, and it's worth knowing the specific capabilities so you can reference them accurately rather than gesturing vaguely at "our AI security story."
Okta's agent discovery and governance capabilities — announced as part of its non-human identity (NHI) governance push — address the inventory problem: knowing what agents exist in your environment, what service accounts they're running under, and what access those accounts have. This is real and valuable. You cannot govern what you cannot see, and most enterprise environments currently have no systematic way to discover and catalog AI agents the way they catalog human users or traditional service accounts.
Okta's Extensible Auth Architecture (XAA) is its framework for extending authentication to non-human principals in ways that the traditional Okta auth flow wasn't designed to handle — including agents that need to authenticate to downstream systems dynamically, without a human in the loop. The short-lived credential approach for machine identities fits here: rather than long-lived API keys that accumulate privilege over time, the architecture issues credentials with defined, short lifetimes that force re-attestation.
These capabilities address the credential anchor problem more directly than the delegation depth or audit chain problems. Okta can tell you that an agent is running under a specific, governed identity with a short-lived credential. It cannot yet tell you whether the authorization decision that caused the agent to take a specific action at 2am was within the scope of what the human intended when they kicked off the task six hours earlier. Nobody in the industry has answered that question yet. The governance layer for agentic decision-making doesn't have an agreed-upon shape.
Be honest about this distinction. The buyer who's asking the hard question will respect the honesty. The buyer who gets a clean answer will eventually notice it was wrong.
What You Do With This Tuesday
You don't need to solve agent identity governance to have a credible conversation about it. You need to be able to follow the CAIO's concerns without either bluffing fluency or freezing.
Know the four specific places where IDAM intuition breaks down in agentic systems. Know what Okta has publicly announced and what problem each capability addresses. Know that the field is actively working on the rest — that the OWASP and CoSAI workstreams exist, that standards bodies are engaged, that this is a recognized unsolved problem rather than a gap someone forgot to fill.
When the CAIO asks whose identity it is when the sub-agent makes the privileged call, a product name won't hold up. The answer that does: "That's the question the field is working hardest on right now. Here's what we can govern today, here's where the architecture is still being defined, and here's how we'd want to approach the interim risk." Giving that answer requires knowing exactly what "what we can govern today" actually covers, which is why the credential anchor and inventory capabilities matter to name precisely.
The CAIO who asked that question in the federal AI meeting last fall wasn't looking for a vendor who had solved it. They were looking for a vendor who understood why it was hard. That's a bar you can clear, and it's a higher bar than most of the room was clearing.
The question "who is this?" has a clean answer in every IDAM system you've ever worked with. In agentic AI, it's still being negotiated. Knowing that is the beginning of a useful conversation, not the end of one.