Agent IAM readiness is lagging behind autonomous AI adoption

At a glance

What this is: This is an analysis of why agent IAM programmes are not ready for agentic AI identities and where current authentication, authorisation, and compliance models break down.

Why it matters: It matters because identity teams now have to govern software entities that can make runtime decisions, which changes how access, accountability, and lifecycle controls must be designed across NHI, autonomous, and human programmes.

👉 Read Ory's analysis of Agent IAM and agentic AI identity readiness

Context

Agent IAM is the identity layer for software entities that can act on their own, and that changes the governance problem as much as the technical one. Traditional IAM assumes identity is provisioned, reviewed, and constrained through stable patterns of use, but agentic systems can shift actions and tool use during runtime.

The result is a gap between how organisations manage access today and how autonomous systems actually behave. That gap affects authentication, authorisation, logging, recertification, and compliance evidence, especially when AI agents operate across workflows that were never designed for independent decision-making.

For teams building identity programmes, the question is no longer whether agents will need access, but whether current controls can still express accountability once access is tied to runtime action rather than a human request.

Key questions

Q: How should security teams govern agent IAM when agents make runtime decisions?

A: They should treat the agent as a distinct identity class with its own delegated scope, session boundaries, and approval rules. The key is to separate authentication of the agent instance from authorisation of each action path. If the system can choose tools or sequence actions dynamically, the control model must review runtime behaviour, not just initial access.

Q: Why do traditional IAM controls struggle with agentic identity?

A: Traditional IAM assumes access can be reviewed and governed as a stable entitlement. Agentic identity breaks that assumption because authority may be exercised in a session-specific, context-driven way. Teams need controls that monitor action selection and tool use, not just login success and token status.

Q: What breaks when authorisation is based only on the agent's starting permissions?

A: You lose sight of authorisation drift. An agent may begin within scope and then expand its effective access by chaining tools or changing actions as context changes. If governance only checks the starting permission set, it can miss the actual path the agent took through the environment.

Q: Which identity evidence do auditors need for agent IAM?

A: Auditors need more than activity logs. They need approved scope, execution boundaries, escalation rules, and records showing when delegated authority changed. Without that context, the organisation can describe what the agent did but cannot demonstrate whether the access was still legitimate at the time of action.

Technical breakdown

Agent IAM, authentication, and delegated identity

Agent IAM extends identity controls to software entities that act on behalf of a system or user, but agentic behaviour makes delegated identity harder to pin down. Authentication may still prove the agent instance, yet that does not explain what the agent is allowed to do once it begins selecting tools, data sources, or workflows dynamically. The core technical challenge is that proof of identity is not the same as proof of intent, and intent is often the missing layer in agent governance.

Practical implication: teams need to separate agent authentication from delegated authority and define where runtime authorisation actually begins.

Authorisation drift in autonomous workflows

Authorisation drift occurs when the permissions granted at the start of a session no longer match the actions taken later in that session. In agentic systems, that drift can happen because the agent chooses new tools, chains actions, or alters its path as context changes. Static policy models struggle here because they assume the access path is known in advance. For autonomous behaviour, the access path is often discovered during execution, not before it.

Practical implication: policy design must account for runtime tool selection and action chaining, not only pre-approved scopes.

Compliance evidence for agent identity governance

Compliance becomes difficult when the thing being reviewed is not a person and not a fixed workload, but a software actor whose behaviour changes per session. Logs may show what the agent did, but they do not automatically prove that access was appropriate at the moment of decision. That creates a control gap between event logging and governance evidence. Without explicit records of delegated scope, authorisation context, and execution boundaries, audit teams are left with activity trails that are descriptive but not sufficient.

Practical implication: audit evidence must capture delegated scope and runtime authorisation context, not just raw activity logs.

NHI Mgmt Group analysis

Agent IAM is becoming a distinct governance layer, not a feature of existing IAM. Agentic systems change the unit of control from user or workload to runtime-decisioning software, which means access, assurance, and accountability have to be designed together. Existing IAM tools can still authenticate and authorise, but they do not automatically govern the behavioural layer that agentic systems introduce. The implication is that identity programmes now need a separate operating model for agent identities.

Least privilege is designed for known tasks, and that assumption weakens when an agent can choose tasks at runtime. Human and workload identity models assume the actor's purpose can be described in advance, then constrained accordingly. That assumption fails when the system can sequence tools and actions dynamically, because the effective privilege path is not fixed at provisioning time. The implication is that static entitlement design alone no longer describes the real risk envelope.

Compliance evidence breaks down when activity logs are mistaken for governance proof. Agent behaviour can be observable without being governable if the organisation cannot show what scope was approved, when it changed, and who owns the decision chain. That makes runtime authorisation context a first-class control concern, not a documentation issue. The implication is that teams must treat agent evidence as a governance artefact, not just an audit afterthought.

Agent IAM will converge with NHI governance faster than many IAM teams expect. Once a software actor can act independently, the same lifecycle questions that apply to service accounts reappear in a more dynamic form: provisioning, scope, review, suspension, and offboarding. The difference is that the agent can modify its own path through the environment while the session is still live. The implication is that NHI and autonomous governance models will need to be managed as one discipline, not separate silos.

From our research:

• From our research: 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, see OWASP Agentic AI Top 10 for the risk areas that agent IAM programmes need to address.

What this signals

Agent IAM will become a control boundary, not just a policy topic. Once organisations let software actors make runtime choices, they need governance that spans identity, permissions, and behavioural oversight in a single operating model. Teams that keep treating agent access as an extension of workload identity will miss the point where delegated authority turns into operational risk.

The most useful next step is to connect agent governance to the same lifecycle discipline used for NHI and human identity, then extend it for session-level change. That means reviewing where approval, revocation, and evidence collection happen today, and whether they still make sense when the actor can alter its own execution path.

For programme owners, the practical question is no longer whether agents need access, but whether current control points can still prove legitimacy after the agent has already acted. That is where the identity model needs to move before the first large-scale deployment becomes the first large-scale governance gap.

For practitioners

• Define a separate agent identity control plane Map which controls apply to human users, which apply to non-human identities, and which must be added for runtime agent behaviour. Treat delegated authority, tool scope, and execution boundaries as distinct control layers.
• Review authorisation models for runtime drift Test whether current policy engines can handle an agent that changes tool use or task sequence mid-session. If they cannot, mark those workflows as requiring tighter approval boundaries or narrower delegated scope.
• Instrument audit trails with governance context Capture approved scope, session boundaries, and escalation conditions alongside raw logs. Without that context, reviewers can see what happened but cannot prove whether the access was still valid when the action occurred.
• Align offboarding and suspension to agent behaviour Build procedures for revoking agent access when models, prompts, tools, or business purpose change. A suspended agent should lose its delegated path immediately, not after a periodic review cycle.

Key takeaways

• Agentic AI creates an identity problem because runtime decision-making changes what access means in practice.
• Current IAM models can authenticate agents, but they often cannot prove that authorisation remained valid throughout execution.
• Identity teams need a separate governance model for agent behaviour that connects delegated scope, runtime control, and audit evidence.

Key terms

• Access-Centric IAM: Access-centric IAM treats access as a lifecycle process rather than a static entitlement. It links issuance, renewal, usage, and removal so security teams can govern human and non-human identities with the same operating logic across hybrid environments.
• Permission Drift: Permission drift is the gradual expansion of access beyond what was originally intended. It happens when roles, tokens, and service accounts accumulate unused rights over time, making cloud identities harder to review and more dangerous to compromise.
• Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.

What's in the full article

Ory's full article covers the operational detail this post intentionally leaves for the source:

• Practical explanation of how the Agent IAM model is positioned for authentication, authorisation, and compliance workflows.
• Implementation context for teams evaluating identity controls around autonomous decision-making systems.
• Editorial framing on why most organisations remain unprepared for agentic AI identity risk.
• Additional operational detail on the identity and access management challenges that agentic AI introduces.

👉 Ory's full article covers the authentication, authorisation, and compliance implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.