AIAM, or AI identity and access management, is the discipline of giving every AI agent its own verifiable identity, a lifecycle tied to a named human sponsor, credentials that expire, and a runtime authorization decision on each action it takes. The term was coined by KuppingerCole and the same discipline is called Agentic IAM by the Coalition for Secure AI. AIAM extends the identity stack an organization already runs, treating agents as first-class identities alongside human users and workloads rather than adding a parallel agent-only system.

How is AIAM different from traditional IAM?

AIAM differs from traditional IAM because AI agents fit neither of the principal types IAM was designed for. Human identities are long-lived, role-governed, and anchored to an HR record, and workload identities run predictable code with static permissions. Agents are autonomous, non-deterministic, spawn sub-agents at runtime, act on behalf of many users, and hold whatever credentials they are given. AIAM adds per-instance identity, a sponsor-linked lifecycle, ephemeral credentials, and per-action runtime authorization to close those gaps.

What is the difference between AIAM and agentic IAM?

AIAM and agentic IAM describe the same discipline under two names. AIAM is the term used by KuppingerCole in its AI security tooling taxonomy, and agentic IAM is the term used by the Coalition for Secure AI in its March 2026 framework. Both cover representing, authenticating, authorizing, and governing AI agents as verifiable identities with a lifecycle and runtime, context-aware access controls. Practitioners use the terms interchangeably.

Why is authorization the enforcement half of AIAM?

Authorization is the enforcement half of AIAM because an identity only tells you who or what is acting, not whether a specific action should be allowed. An agent can hold a valid, attested, short-lived credential and still be prompted into taking an action it should not take. The control that holds is a runtime policy decision at the point of action that evaluates the agent, the user it acts for, the resource, and the context, and denies before the tool runs. Identity is the input to that decision. Authorization is what turns it into a control.

What does an AIAM lifecycle include?

An AIAM lifecycle includes registering the agent with its own identity, a named human sponsor, a purpose, and a risk tier, issuing it short-lived and narrowly scoped credentials, authorizing each action it takes at runtime against policy, logging every decision with the delegation chain and policy version, and reviewing and revoking its access when the sponsor changes, the purpose ends, or its behavior drifts. The lifecycle is continuous rather than a one-time provisioning step.

How does Cerbos support AIAM?

Cerbos supports AIAM as the enforcement layer rather than the identity issuer. Your identity provider, workload identity system, and agent registry supply who the agent is, who owns it, and what it is for, and Cerbos Synapse fetches that context at decision time. The Cerbos PDP then evaluates every action the agent takes against YAML and CEL policies and returns a deterministic allow or deny before the tool runs, with each decision logged with its policy version and delegation context. Because Cerbos speaks OpenID AuthZEN and is stateless and sub-millisecond, the same layer governs agents and every other non-human identity.

What Is AIAM? AI Identity and Access Management Explained

Your fastest-growing workforce has no HR file. Jonathan Care of KuppingerCole opened with that line at EIC Berlin 2026, and the numbers behind it are not subtle. The 2026 Identity Security Landscape report from Palo Alto Networks puts the ratio at 109 machine identities for every human, and 79 of those 109 are AI agents. Those agents log in, hold credentials, call tools, and delegate to each other. What most of them do not have is a named owner, an expiry date, or anything that decides, action by action, what they are allowed to do.

That gap has a name now. KuppingerCole calls it AIAM, AI identity and access management, and it is the identity team's half of securing agentic AI. Definition pages for the term already exist, and almost all of them stop at giving the agent an identity.

This piece covers the other half, which is enforcement. Identity is the input. Authorization is the enforcement. AIAM needs both, and this is the anchor for a set of deeper articles (coming soon) on per-agent-instance identity, joiner-mover-leaver for AI agents, ephemeral credentials for agents, the agent CMDB, and shadow agents.

What is AIAM (AI identity and access management)?

AI identity and access management, or AIAM, is the discipline of giving every AI agent its own verifiable identity, a lifecycle with a named human accountable for it, credentials that expire, and a runtime authorization decision on each action it takes. It extends the identity stack you already run rather than replacing it, and it treats agents as first-class identities alongside people and workloads.

The term comes from KuppingerCole, where Care defined a six-category taxonomy for AI security tooling at EIC 2026 and placed AIAM under prevention, alongside policy and guardrail engines. The Coalition for Secure AI, an OASIS open project, published the most complete industry framing of the same idea in March 2026 under the name Agentic Identity and Access Management. Same discipline, two labels. We use AIAM here because it is the term the analyst community is standardizing on, and we have written about the adjacent ground before, in what to build before the EU AI Act deadline, multi-hop delegation for AI agents, and why service mesh authorization stops at identity.

Why the IAM you built for humans and workloads breaks for agents

Every identity program you run today was designed around two kinds of principal. Human identities are long-lived, governed by roles, certified in periodic reviews, and anchored to an HR record. Workload identities are predictable, run known code, and carry static permissions. An AI agent fits neither. As Chris Hughes puts it in his analysis of the agentic identity problem, the same agent with the same permissions can take fundamentally different actions depending on the prompt, the conversation, and what an upstream agent handed it. Static authorization becomes a design-time exercise applied to a runtime problem.

Martin Kuppinger drew the line more sharply in his EIC 2026 keynote. An AI identity, he argued, is far closer to a human identity than to a workload identity, and he proposed splitting the loose term non-human identity into autonomous identities, which act on their own behalf, and dependent identities, which do not. Andi Hindle went further in the same week and made the point that non-human principals now outnumber humans so heavily that for infrastructure purposes the human user is the edge case. Homan Farahmand of Gartner said it plainly at Gartner IAM London 2026. Current IAM controls are not built for AI agents.

The breaks are specific. An agent has no HR file, so nothing in your joiner-mover-leaver process notices when its sponsor leaves. An agent spawns sub-agents at runtime, so a class-level identity cannot tell you which instance acted. An agent holds whatever credentials it was given for as long as they last, and most of those credentials are standing. A January 2026 study by CyberArk found that 91% of organizations have at least half of their privileged access always on, and that 45% apply the same privileged access controls to AI agents that they apply to humans.

The AIAM lifecycle, from registration to revocation

AIAM is a loop, not a checklist, and it helps to walk the loop once before going deeper on any part of it.

It starts with registration. An agent gets an identity of its own, ideally per running instance rather than per class, recorded in a registry with a named human sponsor, a purpose, a risk tier, and the systems it is allowed to reach. The CoSAI paper's first imperative is exactly this, treat agents as first-class identities, and Farahmand's framing at Gartner IAM London was that uniquely identifying and registering agents is foundational to everything that follows.

It continues with credentials. The registered identity is issued short-lived, narrowly scoped credentials, minted for a task or a hop rather than a tenure, so that nothing an agent holds outlives the work it was doing. Then every action the agent takes is authorized at runtime. A policy decision point is asked whether this agent, acting for this user, may take this action on this resource, right now, with the current sponsor and lifecycle state as inputs. The decision is logged with the full delegation chain and the policy version that made it. Finally, the identity is reviewed and eventually revoked. When the sponsor moves roles or leaves, when the purpose ends, or when the agent's behavior drifts, access narrows or stops, and the registry records that it did.

Gartner's concept of operation for agent IAM, maps onto the same loop, with registration, ownership, credential management, authorization, audit, and lifecycle sitting around the agent as one connected system.

The rest of our blogs in this series take the loop apart one stage at a time.

AIAM lifecycle loop (1).png

Identity is the input. Authorization is the enforcement.

Now let’s talk about the part most AIAM definitions get wrong by omission. They describe how to issue an identity to an agent, how to attest it, how to give it a credential, and then they stop, as if a well-issued identity were a control. It is not. An identity tells you who or what is acting. It cannot tell you whether the specific action in front of it should be allowed.

Kuppinger made this point about MCP directly. If authorization ends at the MCP server, he said, it is coarse-grained in the way web access management was in the 1990s, and it has to run the full way down to the SAP system and the database behind it. The CoSAI framework says the same thing as its fifth imperative. Authentication and authorization must be enforced at each hop in an agentic chain and at the final enforcement point, the tool, the API, the data system, not only at the initial gateway. Nat Sakimura of the OpenID Foundation compressed the whole argument into one line at EIC. Identification is not trust, discovery is not authority, and metadata is not accountability.

Our co-founder Alex Olivier has been making the operational version of the same point, and he wrote it up from Identiverse 2026. An agent follows its access, not its instructions. Telling an agent not to touch production is a request, and a non-deterministic system will eventually ignore it. The only place that boundary holds is where the action is authorized, where the answer to whether this agent, for this user, may do this, on this resource, right now, is computed fresh and enforced. If the policy says no, the call never runs, whatever the prompt said. That is the enforcement half of AIAM, and it is the half that turns identity from a label into a control. We cover the mechanics of doing it at every hop in per-hop PBAC for delegation.

AIAM - identity is the input, authorization is the enforcement (1).png

Where AIAM sits next to IGA, PAM, and workload identity

If AIAM sounds like tool number forty-six, that is the wrong picture, and the practitioners who have done this at scale are emphatic about it. Rogerio Rondini of PwC framed it at EIC as identity for AI being your core IAM plus your non-human identity controls plus a small set of AI-specific capabilities, and added that buying new tools will not solve the problem. The CoSAI paper's seventh imperative is to reuse existing IAM as the control plane and avoid parallel agent-only stacks.

In practice, each existing layer gets extended rather than replaced. Your identity governance program already runs joiner-mover-leaver for people. AIAM extends it so an agent's lifecycle is tied to a human sponsor's, which is the subject of joiner-mover-leaver for AI agents. Your privileged access and secrets tooling already vaults credentials. AIAM moves agent credentials from standing to ephemeral, covered in ephemeral credentials for AI agents. Your workload identity layer, SPIFFE or its equivalent, already attests what compute is running. AIAM builds per-instance agent identity on top of it, covered in per-agent-instance identity. Your CMDB and discovery tooling already inventory systems. AIAM needs an agent CMDB as the system of record, and discovery to find the shadow agents that never registered. And your authorization layer, if you have externalized one, is the enforcement point that all of the above feeds.

A maturity ladder for AIAM

Care offered a five-stage ladder at EIC. Denial, where the organization believes it does not use agentic AI while three teams already do. Pilots, where agents run in development with controls only on the model, which is where he placed most enterprises. Inventoried, where every agent is registered and its sponsor known, but nothing is enforced at runtime. Governed, where each agent has its own identity, scoped credentials, an audit chain, and a runtime policy check on every call, which he described as table stakes for anything in production. And Adaptive, where authorization is continuous and responds to signals, which is where the leaders are heading.

The CoSAI paper compresses the same climb into three cumulative phases, visibility, contextual access, and full agentic IAM, and is blunt that delaying the first phase increases exposure. The point both ladders share is that the step from Inventoried to Governed is the enforcement half. You can register every agent, assign every sponsor, and rotate every credential, and still be one prompt injection away from an incident if nothing decides at the moment of action.

Why this is the identity team's program, and why it helps you say yes

Boards have mandated AI. Gartner expects 40% of enterprise applications to include task-specific agents by the end of 2026, up from under 5% in 2025, and also expects over 40% of agentic AI projects to be canceled by 2027, partly for inadequate risk controls. The identity team is the group that can supply those controls, and right now most cannot. A Cloud Security Alliance survey of 383 IT and security professionals found that 92% lack confidence that their legacy IAM tools can manage AI and non-human identity risk, and 78% have no documented policy for creating or removing AI identities.

Regulation is arriving on the same timetable. The EU AI Act requires automatic event logging for high-risk systems under Article 12 and human oversight that can override, disregard, reverse, or stop an AI system under Article 14. An identity team that can show a registered agent, a named sponsor, an expiring credential, and a per-action decision log has the evidence a regulator asks for and the control a CISO needs. That is what lets you say yes to the next agent instead of blocking it.

How Cerbos fits

We are not the identity provider, the agent registry, or the secrets vault, and AIAM needs all three. Those are the input side. Your IdP and workload identity layer say who the agent is, the registry says who owns it and what it is for, and the vault or token service hands it a credential that expires. The Cerbos authorization management platform is the enforcement side.

At every action, the service, gateway, or MCP server the agent calls asks the Cerbos PDP whether this agent instance, acting for this user, under this sponsor, with this lifecycle state, may take this action on this resource, and gets back a deterministic allow or deny before the tool runs.

The inputs are what make that decision worth anything, which is why Cerbos Synapse fetches identity, sponsor, and relationship data from your IdP, your registry, and your systems at decision time and delivers a fully enriched request to the engine. The policy can reason about the human behind the agent, the resource being touched, and whether the agent's sponsor still works here, without any of that context being hardcoded into the agent. Policies are YAML with CEL conditions, managed in Cerbos Hub with version history, and every decision lands in an audit log with the principal, resource, action, policy version, and delegation context that Article 12 and your incident review both want. Narrowing an agent that worries you is a policy change the next request obeys, the dimmer switch rather than a kill switch model, and the agent keeps running inside the new boundary. The PDP is stateless and answers in under a millisecond, so checking every action is affordable, and because it speaks OpenID AuthZEN the same enforcement layer covers every non-human identity in the estate, not only agents.

AIAM is the identity team's half of agentic AI, and it is two halves itself. Give every agent an identity, a sponsor, a lifecycle, and a credential that expires, then make sure something decides on every action it takes. The first half is what the definition pages describe. The second half is what keeps the first from being a very well-documented way to get breached.

Try Cerbos to see runtime authorization for agent identities in practice, or book a call to walk through your AIAM program with our team.

Go deeper: