There are two kinds of identities that IAM practitioners have been dealing with for decades: humans who work for your company (workforce), and humans who use your product (consumer). Up until recently, every framework, every vendor, and every tool had structured itself around that split.
For a long time, that worked fine, because those were the only things that really needed identities.
That’s no longer the case.. As preached ad nauseam by every vendor out there for the past year.
There’s a third category that’s been finding it’s way into production environments for the last couple of years and it’s about to blow past the first two in sheer volume alone: agentic identities. AI agents, automated workflows, and LLM-orchestrated pipelines that do what service accounts never could. They can make decisions, call APIs, manage resources, and act on behalf of humans in ways that look a lot less like a service account and a lot more like a person.
No one was really ready for this and we see the results in the headlines every day. The tools weren’t ready. The frameworks still aren’t ready. Most organizations are still slapping authorization flows and tools meant for users onto agentic workloads and hoping for the best.
The good news here is that every vendor in existence started a race to grab as much land in this new security space as possible and people a lot smarter than me are working on fixing it.
First, Let’s Be Clear About What We’re Comparing
Before I get into Agentic IAM specifically, it’s worth grounding the comparison so we’re not talking past each other.
Workforce IAM (WIAM) is identity for employees, contractors, and partners. PAM falls in here typically as well. The core problems it solves is who can access what internal system, how do we provision and deprovision cleanly, how do we enforce MFA and conditional access, and how do we federate identity across the enterprise. The trust model assumes a bounded population of known humans operating on (usually) managed devices. The threat model is usually insider risk, credential theft, and overprivileged accounts.
Consumer IAM (CIAM) is identity for customers. Completely different set of priorities, so completley different flows. The focus is on registration experience, login conversion, social login, progressive profiling, consent management, and fraud detection. CIAM operators are competing for users, so they can’t afford friction. The trust model is essentially zero (every user is a stranger) and the threat model is account takeover, credential stuffing, and bot traffic. This is the whole reason KYC (know your customer) platforms exist.
WIAM and CIAM share largely the same underlying protocols (OIDC, OAuth, SAML) but they’re using them to solve fundamentally different problems. A WIAM deployment optimizes for control and auditability. A CIAM deployment optimizes for conversion and experience. The things that make one good actively make the other bad. Yin and Yang if you will.
Now. Agentic IAM is neither of those things. And that distinction matters.
What Makes Agentic IAM Different
An AI agent, whether it’s an LLM-powered workflow, an autonomous orchestrator, or a tool-using model acting on someone’s behalf, has identity characteristics that do not map well to both WIAM and CIAM:
It acts on behalf of someone, but it isn’t that someone. A human authorizes an agent to do something, but the agent takes the actions. How do we show which agent is trying to act on behalf of which user? How do we determine the permissions? This is a delegation problem that WIAM and CIAM rarely touch, but it’s quickly becoming mandatory. OAuth has actor claims, and there’s work happening in the IETF on identity chaining, but widespread support is thin. Most implementations today just give the agent the user’s token. Which is a freaking disaster waiting to happen.
Its behavior is non-deterministic. A service account typically only does one or two things and only needs that access. The problem now becomes that an agent follows intent, and intent can be hijacked. This can be relatively limited by agent tooling, but prompt injection is the new SQL injection, and nobody that I know has built a WAF for it yet. The assumption baked into most identity systems is that a given credential will be used in predictable ways. Agentic workloads can violate that assumption routinely.
It has dynamic, context-dependent scope requirements. A traditional service account, like we said above, needs a fixed set of permissions. An agent working a support ticket today might need read access to a CRM. The same agent working an escalation tomorrow might need to issue a refund. Static role assignments don’t work well here. You need something closer to just-in-time and just-enough-access (JIT/JEA) permission that grants are scoped to a specific task, and then you need a way to revoke them cleanly as soon as the task is done.
It can spawn sub-agents. Multi-agent architectures are becoming more and more common. This is where an orchestrator delegates tasks to specialized worker agents with minimal access. This create identity chains that, as far as I’m aware, nobody’s really solved. If agent A is acting on behalf of a user and spawns agent B which spawns agent C to handle a task, and agent C calls an external API, who is on the hook for that call? How do we show that access chain? SPIFFE/SVID helps with the infrastructure layer of this, but there’s no widely-adopted standard for credential delegation through agent chains.
The population is massive and ephemeral. You might have 10,000 employees. You might have a few million customers. In an agentic architecture, you could spin up millions of agent instances per hour, each needing some form of identity for the duration of a session to do a specific task. The workload alone is exponential and the lifecycle management patterns for WIAM and CIAM don’t scale to that.
The Four Core Problems Agentic IAM Has to Solve
I’d frame the Agentic IAM problem space around four things:
1. Delegation and Chain of Custody
When a human authorizes an agent, there needs to be a cryptographically verifiable chain from “human said yes”, even if the yes is implied, to “agent took action.” This is more than just storing a user ID. It requires structured delegation tokens that carry both the subject (the agent) and the actor (the authorizing human), with scope constraints that travel through the chain. The OAuth 2.0 Token Exchange spec (RFC 8693) is the right starting point and solves at least the first hop here, but most identity providers implement it poorly or not at all.
2. Minimal Footprint by Default
Agents should operate with JIT/JEA in mind at runtime. This means the minimum permissions needed for a specific task should be granted at the start of that task and revoked as soon as possible when it’s done. This sounds like least privilege (It is.) but the implementation looks different than traditional RBAC. Think Vault dynamic secrets and short-lived tokens as the model, not static role assignments. Agentic IAM needs policy engines that can reason about task context, not just map attributes to static access.
3. Behavioral Trust, Not Just Credential Trust
Presenting a valid credential should get you through the door, but shouldn’t get you unsupervised access to sensitive operations forever. Agentic workloads need continuous evaluation at every enforcement point. Think not just “did you authenticate?” but “is this what this agent would normally do?”. Anomalous behavior (calling APIs it’s never called, accessing data outside expected scope, unusual call volumes) should trigger re-verification or suspension as access is requested, not logging to a SIEM to be reviewed in half an hour. By then it’s way too late.
4. Auditability That Actually Makes Sense
Agentic audit trails need to capture the full decision chain: what did the human authorize, what did the orchestrator decide, what did each sub-agent do, what access did the agent get, and what was the outcome. That’s a different log schema than what most SIEMs are expecting. This is going to be a compliance problem before it’s a tooling problem. We all know that getting funds for cyber tooling is difficult because cybersecurity does not return revenue to the company. Because if this, regulators are going to have to start asking for agent audit trails to force the companies to open up budgets to meet compliance.
Why Shoehorning Doesn’t Work
I see three patterns organizations use today when they need agentic access, and all three are wrong in different ways.
Service accounts: Simple, understood, and terrible for agents. Service accounts typically have static credentials, no inherent delegation model, no behavioral context, and their permissions tend to sprawl over time because nobody knows what they’re used for. Treating an LLM agent like a service account is like giving a contractor a company car and tracking it like a fixed piece of factory equipment. It breaks immediately.
User impersonation: Some orgs just give the agent the user’s OAuth token. This conflates authorization (the user said yes) with identity (the agent is doing the work), which:
- Breaks audit trails
- Makes it impossible to scope agent permissions separately from user permissions
- Means that if the agent is compromised, the user’s full access surface is exposed
Just-in-time access with manual approval: Better! But this is like making every account a PAM account, it doesn’t scale well.. If your agent is taking thousands of actions per day, humans can’t be in the loop on each one. Based on your organizations risk appetite and what the agent is requesting access to do, JIT access needs to be automated, policy-driven, and audited.
What Good Looks Like
The emerging best practice stack for Agentic IAM, as far as I can see it today:
- SPIFFE/SVID for workload identity at the infrastructure layer. This issues a cryptographic identity for the agent itself
- OAuth 2.0 Token Exchange (RFC 8693) for delegation NOT IMPOERSONATION. This gives the agent a token that carries the authorizing user or agent’s context without carrying their full permissions
- Short-lived, task-scoped secrets from a secrets manager (Vault being the obvious choice) rather than static credentials
- Policy engines (OPA, Cedar, Vault’s ACL engine, your IdP’s, etc.) to enforce context-aware authorization at runtime
- Structured audit logging that captures delegation chains, not just API calls
The good news is that none of this is new technology. The gap is in how we can currently wire it all together for agentic workloads specifically and in vendor platforms that surface these controls in ways that non-infrastructure teams can actually configure.
The big players are moving. Okta, Microsoft, Ping, and others have agentic identity on their roadmaps. Some are already shipping early features. But the tooling is fractured and the standards are all over the place.
My Take
Agentic IAM is going to be the dominant identity problem of the next five years. Not because Workforce or Consumer IAM is going away. They’re not and god help you if that’s what you’re still struggling with right now. But because the volume, complexity, and attack surface of agentic workloads will dwarf everything else. And right now, most organizations I’ve talked to have basically no coherent strategy for it.
The orgs that get ahead of this will treat agentic identity as a first-class IAM discipline with its own patterns, tooling, and governance, not as a WIAM edge case. That means updating your identity architecture to accommodate delegation chains. It means rethinking your audit and monitoring strategy for non-human actors. It means having an opinion on how your agents authenticate before your security team finds out they’re using long-lived service account keys in environment variables.
(And they are using long-lived keys in environment variables. I promise.)
Build the third pillar before the agents and developers build something you can’t audit.
TL;DR
- IAM has two established pillars: Workforce (WIAM) and Consumer (CIAM). A third is emerging: Agentic IAM.
- Agentic identities are fundamentally different. They act on behalf of humans, have non-deterministic behavior, need dynamic scoping, and can spawn other agents.
- The four core problems: delegation and chain of custody, minimal footprint by default, behavioral trust, and meaningful auditability.
- Shoehorning agents into service accounts or user impersonation is a security and compliance risk. Stop doing it if you are.
- The right bascis exist (SPIFFE, Token Exchange, Vault, OPA). The gap is coherent architecture and vendor tooling that makes it accessible. For now.
- Agentic IAM will be the dominant identity discipline of the next five years. Get ahead of it now.