TL;DR: AI agents are already powering hundreds of workflows and are expected to outnumber humans 80:1 in large enterprises, but most still operate without identity guardrails, according to Strata Identity. Traditional IAM assumptions break when identity, access, and audit must move at machine speed, not human pace.
At a glance
What this is: This guide argues that agentic AI requires a different identity model because agents are already operating across workflows faster and at larger scale than human-centric IAM was designed to handle.
Why it matters: IAM, PAM, and lifecycle teams need to account for AI agent identity, delegated access, and traceable behaviour before agent sprawl turns into ungoverned machine privilege.
By the numbers:
- 80:1 That’s how many more agents than humans large enterprises are expected to manage in the next few years.
- 100s of workflows already powered by AI agents today from refunds and IT automation to cross-cloud orchestration.
👉 Read Strata Identity's guide to agentic identity and AI agent governance
Context
Agentic identity is the problem of governing software entities that decide, act, and access resources at runtime rather than following a fixed script. This matters because identity controls built for people or static service accounts do not naturally fit AI agents that can move across tools, workflows, and environments in the same session.
Strata Identity frames the issue as agent sprawl: more agents, more workflows, and more access paths, but little corresponding guardrail maturity. For identity teams, the question is not whether AI agents will join the estate, but how to make their access traceable, bounded, and auditable without slowing the systems they operate in.
Key questions
Q: How should security teams govern AI agent identities in enterprise environments?
A: Treat AI agents as governed identities with named owners, explicit delegated scope, and lifecycle controls. The practical goal is not just to grant access, but to bind every action to a principal, a policy, and an auditable purpose. If the team cannot inventory the agent, constrain its tools, and retire it cleanly, it is not governed.
Q: Why do AI agents create different identity risks than service accounts?
A: Service accounts are usually static identities with predictable access paths, while AI agents can change behaviour at runtime by choosing actions and tools in response to context. That makes access less like a fixed entitlement and more like a live decision problem. Traditional IAM controls struggle when the subject itself is making execution choices.
Q: What breaks when AI agents are added to an IAM programme without new controls?
A: Visibility breaks first, followed by auditability and accountability. Without a registry, policy binding, and delegated authority model, teams cannot reliably tell which agent accessed what, under whose approval, or for which workflow. The result is machine privilege that exists outside normal review and offboarding processes.
Q: Who should own AI agent governance in the identity stack?
A: Ownership should sit with identity and security teams together, because agent governance spans access policy, audit, lifecycle, and platform integration. It cannot live only in application teams or only in infrastructure operations. The right model is shared accountability with a single control plane for policy and revocation.
Technical breakdown
Why traditional IAM breaks down for AI agents
Traditional IAM assumes a stable subject, a known workflow, and a human-paced control loop. AI agents break that model because they can request, combine, and use access dynamically as they execute tasks. That creates a mismatch between provisioning-time policy and runtime behaviour. In practice, authentication, authorisation, audit, and administration all need to operate against a subject that may be short-lived, delegated, or replicated across many workflows. Without a control plane built for machine speed, identity governance becomes retrospective instead of preventative.
Practical implication: Treat AI agents as first-class identities with runtime policy and traceability, not as extensions of user accounts or service accounts.
On-behalf-of delegation and traceable agent behaviour
On-behalf-of delegation is the pattern that lets an agent act with constrained authority tied back to a principal, rather than inheriting broad ambient privilege. The value is not just access brokerage. It is accountability: every action should remain attributable to the initiating identity, the delegated scope, and the policy that authorised the request. Dynamic policies are essential here because static entitlements cannot express transient task scope well enough for agentic execution. If the chain of responsibility is not preserved, audit becomes an after-the-fact reconstruction exercise.
Practical implication: Use delegation design that preserves principal context and logs every agent action against the governing policy and initiating identity.
Agent fabric, registry, and identity orchestration
An agent fabric is an identity and control layer that discovers agents, registers them, and mediates access across clouds, platforms, and disconnected environments. The registry provides inventory and lineage. Identity orchestration coordinates policy, access, and observability across the full lifecycle of the agent. This matters because agent sprawl is not just a scaling problem, it is a governance fragmentation problem. If different teams can spawn, connect, and retire agents independently, you lose the ability to answer basic questions about who can do what, where, and under which control plane.
Practical implication: Build a central registry and orchestration layer so agent identity is visible, governable, and revocable across environments.
NHI Mgmt Group analysis
AI agent identity is now a governance category, not a feature request. Once agents can act across workflows, access is no longer a simple entitlement problem. It becomes a question of whether the identity layer can describe, constrain, and audit independent runtime behaviour. Practitioners should treat agent identity as its own control domain, adjacent to but distinct from human IAM and classic workload identity.
Standing access assumptions fail when the subject is an agent. The idea that identity is assigned to a stable principal for a predictable purpose was designed for fixed users and long-lived workloads. That assumption fails when agents are created, delegated, and repurposed across hundreds of workflows. The implication is that governance has to track changing intent, not just static permission sets.
Agent sprawl creates identity blast radius faster than most programmes can inventory it. When hundreds of workflows can be powered by agents, the question becomes how quickly access paths multiply and how much control is lost outside the central identity plane. This is where visibility, registration, and policy enforcement become operational necessities rather than architecture preferences.
Identity orchestration is the missing control layer for machine-speed access. The article points to a reality many IAM programmes have not yet absorbed: agents need coordinated identity controls across apps, clouds, and environments without refactoring every system. That makes orchestration the mechanism that turns fragmented access into governable access. Practitioners should evaluate whether their current stack can coordinate access decisions across the full agent lifecycle.
Autonomous behaviour changes the trust model, even when the underlying identity mechanism looks familiar. A service account can be governed as a static machine identity. An agent can decide when to act, what to call, and how to chain tools, which turns identity from a record of access into a live control problem. The implication is that identity governance must account for runtime decision-making, not just provisioning state.
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 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.
- The gap is not just visibility, it is governance maturity, as the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows with offboarding and rotation controls.
What this signals
Agentic identity governance will become a control-plane issue, not a point-solution issue. As AI agents spread across refunds, IT automation, and cross-cloud orchestration, identity teams will need a way to see every subject, every delegated scope, and every revocation path in one place. The organisations that delay this shift will discover that access reviews do not help when they cannot enumerate the actor set in the first place.
Agent sprawl creates a new form of identity blast radius. If 80:1 agent growth materialises, the operational challenge is not just more identities, but more ways for policy drift and orphaned access to accumulate. Teams should expect lifecycle tooling, audit pipelines, and access governance to converge around machine identities rather than remain separate towers.
The practical signal for programme owners is that agent governance now belongs beside NHI lifecycle and privileged access in the roadmap. That means defining owners, inventory standards, and revocation paths before the first large-scale workflow goes live, not after audit or incident response forces the issue.
For practitioners
- Inventory every AI agent as a governed identity Create a complete agent registry that captures purpose, owner, delegated scope, connected tools, and retirement criteria. If you cannot answer who owns the agent and what it may access, it is already outside governance.
- Apply on-behalf-of delegation with bounded scope Bind agent actions to an initiating principal and enforce task-scoped permissions rather than broad reusable access. Preserve principal context in logs so audit teams can reconstruct the full chain of authority.
- Centralise policy with identity orchestration Use one control layer to coordinate access decisions across cloud, on-premises, and disconnected systems. That reduces the chance that separate teams create incompatible agent identities with inconsistent permissions.
- Extend audit to machine-speed behaviour Log not only successful access but also tool selection, delegation changes, and policy decisions made during execution. If agent actions cannot be traced back to a policy and a principal, the programme does not yet have usable audit evidence.
- Review lifecycle offboarding for agents Define how an agent is disabled, revoked, and removed from orchestration when a workflow ends or a model changes. Agent retirement should be as explicit as provisioning, because orphaned agents become persistent access paths.
Key takeaways
- AI agent identity cannot be governed with human-centric IAM assumptions because agents act at runtime across many workflows.
- Strata Identity's guide highlights both the scale problem and the governance gap, with 80:1 projected agent growth and only partial policy adoption today.
- Identity teams should move now on inventory, delegated scope, and lifecycle revocation so agent behaviour remains traceable and bounded.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent autonomy and tool use are central to this guide's identity model. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | The guide centres on machine identity governance and lifecycle control. |
| NIST AI RMF | Agentic identity requires governance over behavior, accountability, and trust. |
Inventory agent identities, bind owners, and revoke access through explicit lifecycle processes.
Key terms
- Agentic Identity: The identity and access model for software entities that can decide and act at runtime. It extends machine identity governance into systems that choose tools, sequence actions, and execute work with limited or no human approval. The control challenge is accountability, scope, and revocation at machine speed.
- On-Behalf-Of Delegation: A delegation pattern where an agent acts with authority tied back to an initiating principal. It preserves traceability by linking each action to the original subject and the policy that authorised it. For autonomous or semi-autonomous systems, it is essential for audit and responsibility.
- Agent Fabric: An identity control layer that discovers, registers, and manages agents across environments. It provides visibility into where agents exist, what they can access, and how they are governed. In practice, it reduces sprawl by giving security teams a central place to coordinate policy and lifecycle controls.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.
This post draws on content published by Strata Identity: Field guide to agentic identity. Read the original.
Published by the NHIMG editorial team on 2025-07-24.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org