For decades, identity systems were largely designed around people and predictable machine workloads.
AI agents introduce actors that can make decisions, chain actions and operate continuously.
IAM therefore needs to evolve from managing access to governing action and authority.
Key Takeaways
- Agentic AI does not replace IAM; it exposes areas where existing identity models need to become more dynamic.
- Identity needs to account for autonomous and non-human actors, not only human users.
- Delegation, runtime authorisation and contextual policy become increasingly important when agents can act independently.
- Existing identity governance disciplines provide much of the foundation required for the agentic enterprise.
The foundations are still right
Authentication still matters.
An organisation still needs to know which identity is making a request.
Authorisation still matters.
It still needs to determine whether that identity should be allowed to access a resource or perform an action.
Lifecycle management still matters.
Identities still need to be created, maintained, reviewed and retired.
Auditability still matters.
Organisations still need evidence of what happened.
None of those principles become obsolete because the actor happens to be an AI agent.
The challenge is that agents introduce new requirements around autonomy, delegation and runtime context.
From login to action
Traditional IAM often establishes trust at a particular point in time.
A user authenticates. A session begins. Permissions are evaluated. The user then interacts with applications within the boundaries established by that identity and session.
Agentic workflows can be different.
An agent may operate over an extended period, call several services, receive new information and determine its next action dynamically.
A decision made when the agent was initially authorised may no longer be sufficient when the agent reaches the next step.
This is why runtime identity is becoming an important part of the discussion.
The security boundary moves closer to the action itself, with identity, delegation and context evaluated when the request occurs.
From impersonation to delegation
Another important shift is how agents represent people.
A straightforward implementation might allow an agent to use the same credentials as a human user.
It can work technically.
It creates problems operationally.
The organisation loses a clear distinction between the human and the software acting on their behalf.
Delegation provides a better model.
The human remains the principal. The agent receives defined authority to perform a particular set of actions.
That relationship can then be constrained, reviewed and revoked independently.
It also creates a more useful audit trail.
Rather than asking only which credential was used, the organisation can ask which agent acted, for whom, with what authority and against which resource.
From static privilege to contextual privilege
Least privilege has traditionally meant limiting the permissions associated with an identity.
For agents, the concept needs to become more contextual.
An agent may legitimately perform one action and be denied another using the same underlying application.
It may be permitted to access a resource during one workflow but not another.
It may be allowed to read information but require human approval to modify it.
Ping's current agent identity guidance describes this as dynamic, context-aware authorisation and emphasises short-lived, scoped access and runtime evaluation.
The result is not a new form of IAM so much as an evolution of where and when identity decisions are enforced.
Governance still needs a lifecycle
There is another reason not to think of agent identity as a standalone security problem.
An agent has a lifecycle.
It is created.
Someone owns it.
It receives access.
Its purpose may change.
Its permissions may change.
Eventually it is retired.
Those are identity governance processes.
The challenge is extending established governance practices to a population of agents that may grow quickly and operate across different applications and environments.
Discovery therefore becomes important.
Organisations cannot govern agents they do not know exist.
Ownership becomes important.
An organisation cannot hold an anonymous software component accountable.
Lifecycle becomes important.
An agent should not retain access indefinitely simply because nobody remembered to remove it.
IAM becomes part of AI governance
This is where the distinction between AI governance and identity governance becomes useful.
AI governance establishes what an organisation considers acceptable.
Identity and authorisation help enforce those decisions.
For example, an AI governance policy may say that an agent cannot access sensitive customer information unless the task requires it.
Identity controls can help determine whether the agent is authorised to access that information.
AI governance may require human approval for a high-impact action.
Identity and authorisation controls can enforce the approval requirement at the point of execution.
The two disciplines therefore complement each other.
Neither replaces the other.
The agentic enterprise needs both
The organisations best positioned to scale agentic AI are unlikely to abandon their existing identity investments.
They will extend them.
They will treat agents as governed identities.
They will make delegation explicit.
They will apply least privilege to autonomous actors.
They will introduce runtime decision-making where static permissions are insufficient.
And they will retain the governance disciplines that have always mattered: ownership, lifecycle management, monitoring and auditability.
The evolution of IAM is therefore not about starting again.
It is about moving identity closer to the moment where trust is actually required.
The agentic enterprise does not need less identity. It needs identity that can keep pace with how software now acts.
