TL;DR: AI-era identity security is moving faster than governance, and Veza cites a CSA survey showing only 26% of organisations have comprehensive AI security policies in place, while the updated OWASP Top 10 for LLM Applications signals a shift toward agent-centric risk. The practical issue is that least privilege and access control must now account for AI agents as governed identities, not just workloads.
At a glance
What this is: Veza’s white paper argues that identity security must become the control plane for AI agents and LLMs, with governance lagging current deployment speed.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat AI agents as governed identities because existing policy and access models were not built for their runtime behaviour.
By the numbers:
- Only 26% of organisations report having comprehensive AI security governance policies in place.
- The updated OWASP Top 10 for LLM Applications indicates a significant shift in cybersecurity centered on AI agents.
- Only 5.7% of organisations have full visibility into their service accounts.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
👉 Read Veza's white paper on operationalising the OWASP Top 10 for LLMs
Context
AI agent identity security is now an identity governance problem, not just an application security one. Once agents can access tools, data, and downstream systems, the question becomes who or what is authorised, how that access is constrained, and how it is monitored across the identity lifecycle. That brings the issue directly into NHI governance, IAM, and access control.
Veza’s white paper is useful because it connects AI security to identity control plane thinking rather than treating agents as a separate category. The operational gap is familiar: organisations are deploying faster than their governance policies, reviews, and privilege controls can keep up. For identity teams, that means the same control failures that affect service accounts now apply to AI-driven access paths as well.
Key questions
Q: How should security teams govern AI agents that can change behaviour at runtime?
A: Security teams should govern AI agents with runtime monitoring, behavioural baselines, and identity-triggered response, not just static approval workflows. The goal is to detect when an agent drifts from expected purpose, reduce privileges immediately, and keep accountability tied to a named owner. In agentic environments, governance must work at machine speed rather than review cadence speed.
Q: Why do AI agents complicate least privilege for IAM programmes?
A: AI agents complicate least privilege because their access is task-driven and may change during execution. Human IAM can often map privilege to role and job function, but agents combine context, tools, and delegated actions dynamically. That makes least privilege a runtime governance problem, not just a provisioning decision.
Q: What do IAM teams get wrong about agent users and human users?
A: They often assume that a user-shaped object means a human-style identity process. In this model, the agent user is only an interface layer for services that expect a user object, while the actual execution root remains the agent identity. Treating the agent user as a person leads to the wrong review, offboarding, and privilege model.
Q: Should organisations use a dedicated AI agent identity model or extend current NHI controls?
A: Extend current NHI controls first, but only if they include ownership, scope, lifecycle, and revocation discipline. The mistake is treating AI agents as just another service account when they may combine permissions dynamically at runtime. A dedicated model is warranted when delegation chains span multiple applications and control ownership is unclear.
Technical breakdown
AI agent identities and the identity control plane
AI agents become security-relevant when they can authenticate to systems, request data, and act through tools or APIs. At that point, they are governed identities, even if they are not human users and do not behave like traditional workloads. The control plane question is not whether an agent exists, but whether its access can be discovered, constrained, reviewed, and revoked like any other identity that can affect data or operations. Practical identity governance needs to treat agent entitlements as first-class objects.
Practical implication: Map every agent to an owner, a purpose, and a revocation path before it touches production systems.
Least privilege for AI agents and LLM applications
Least privilege in agentic environments is harder because access is often assembled across prompts, tools, connectors, and external data sources. A conventional role model may say the identity has one permission set, while runtime behaviour actually creates wider effective access through chained tools and indirect reach. That is why agent governance cannot stop at static entitlements. It has to account for the full action path, including what the model can retrieve, invoke, and hand off to other systems.
Practical implication: Review the effective tool chain, not just the assigned role, when deciding whether an AI agent is over-privileged.
Why AI security governance policies lag deployment
Governance lag usually appears when security controls are written for software delivery speed, not for identities that can adapt at runtime. The article’s 26% figure is consistent with a broader pattern: teams often have policy language for AI, but not a durable operating model for access reviews, approval boundaries, monitoring, and offboarding. In identity terms, the policy exists without the lifecycle mechanics that make it enforceable. That is the real gap.
Practical implication: Tie AI policy to lifecycle controls, access reviews, and monitoring events so governance can actually be executed.
NHI Mgmt Group analysis
AI agents should be governed as identities before they are governed as applications. Once an agent can authenticate, call tools, and access data on its own behalf, the relevant control question shifts from software assurance to identity assurance. That creates a direct overlap with NHI governance, because the access path behaves like any other non-human identity with runtime privileges. Practitioners should treat agent identity as part of the core identity estate, not a sidecar concern.
Least privilege becomes materially harder when access is assembled at runtime across tools and connectors. Traditional IAM assumes entitlements can be understood from a provisioning record. Agentic systems blur that boundary by composing access from multiple systems and execution steps. The result is effective privilege that can exceed the formal role model, which is why access governance needs to inspect runtime pathways, not just static assignments.
Policy without lifecycle enforcement is not governance. Veza’s cited survey signal fits a wider identity pattern: organisations can write AI security rules faster than they can operationalise ownership, review cadence, revocation, and monitoring. That makes the policy a statement of intent rather than a control. The practitioner takeaway is that AI identity programmes fail when they stop at documentation and do not connect to access administration.
Identity security for AI agents will converge with NHI governance rather than replace it. The same control disciplines that now apply to service accounts, API keys, and workload identities will extend to agentic systems because the underlying risk is access without sufficient governance. The category is not separate; it is an expansion of the non-human identity problem. Teams should plan for shared governance models across machine, agentic, and human identity domains.
OWASP and identity governance are now pointing at the same failure pattern: uncontrolled runtime authority. The updated OWASP Top 10 for LLM Applications reflects a category shift toward agent-centric risk, while identity teams are already seeing that access reviews and entitlement models struggle with dynamic behaviour. That convergence matters because it tells practitioners the problem is not only model safety. It is control over what the model can do once it becomes an actor in the environment.
From our research:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- From our research: 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
- From our research: See the NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding fit into a governed identity programme.
What this signals
Runtime governance gap: AI agent programmes fail when identity teams treat agents as software features instead of governed actors with access, owners, and a revocation path. The next maturity step is not more AI policy language. It is the extension of lifecycle controls into the agent control plane, with NHI Lifecycle Management Guide discipline applied to non-human access.
With the Ultimate Guide to NHIs showing that NHIs outnumber human identities by 25x to 50x in modern enterprises, the scaling problem is already established. AI agents add another layer of dynamic access, so the operational question becomes whether your IAM stack can discover, review, and revoke authority fast enough to keep pace.
The control model is shifting toward identity-centric AI governance, and the relevant standards are converging around access, monitoring, and accountability. For practitioners, that means mapping agent access to existing IAM and NHI processes now, rather than waiting for a separate AI governance programme to catch up.
For practitioners
- Define a governed owner for every AI agent Assign business and technical ownership before an agent receives tool access, and require a revocation path that can be executed without dependency on the model runtime.
- Inventory the effective tool chain Document every connector, API, retrieval source, and delegated system an agent can reach, then review the full chain for privilege expansion beyond the assigned role.
- Bind policy to access lifecycle controls Connect AI policy to onboarding, access review, monitoring, and offboarding events so approvals and revocations are enforceable rather than advisory.
- Review agent privileges as runtime pathways Assess what the agent can do during execution, including indirect access through tools and handoffs, instead of relying only on static entitlement lists.
Key takeaways
- AI agents are becoming identity governance problems as soon as they can access tools and data on their own behalf.
- Static entitlements are not enough when effective privilege is assembled at runtime across connectors and delegated systems.
- Practitioners should extend NHI lifecycle controls into agent governance before policy outpaces enforceable access control.
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 CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | The article centers on OWASP's updated LLM and agentic application risks. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI agents here are governed as non-human identities with access and lifecycle needs. |
| NIST CSF 2.0 | PR.AC-4 | The topic is fundamentally about access control and least privilege. |
| NIST AI RMF | GOVERN | AI governance policy and accountability are central to the article's argument. |
| NIST Zero Trust (SP 800-207) | AI agent access control fits zero trust identity assumptions and continuous verification. |
Inventory agent identities, ownership, and access scope under OWASP-NHI before granting production entitlements.
Key terms
- AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
- Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.
- Legacy Access Path: A legacy access path is an older permission route that remains active after newer, tighter controls have been added. These paths are dangerous because they are easy to forget, often poorly monitored, and frequently become the easiest route for attackers once modern workflows are hardened.
- Effective Privilege: Effective privilege is the real access an entity can exercise after inheritance, delegation, token scope, and connected-system trust are applied. It is often broader than the permissions shown in an identity repository, which is why runtime validation matters.
What's in the full article
Veza's full whitepaper covers the operational detail this post intentionally leaves for the source:
- How the platform frames identity security as the control plane for AI agents and LLM access
- The specific least-privilege strategies it recommends for agent identities at scale
- The survey context behind the 26% AI security governance figure and what it implies for programme maturity
- How its NHI and AI agent security capabilities are positioned across access visibility, monitoring, and governance
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.
Published by the NHIMG editorial team on August 25, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org