AI agent identity governance is lagging behind security policy

At a glance

What this is: This whitepaper argues that AI agent identity governance is trailing the speed of AI adoption, with governance policy maturity lagging behind the rise of agent-centric risk.

Why it matters: It matters because IAM, IGA, and PAM teams now need controls that govern AI agents as identities, not just as application extensions or automation targets.

By the numbers:

• Only 26% of organisations report having comprehensive AI security governance policies in place, according to Veza.
• The updated OWASP Top 10 for LLM Applications indicates a significant shift in cybersecurity centered on AI agents, according to Veza.

Context

AI agent identity governance is the discipline of controlling how AI agents are identified, authorised, reviewed, and constrained when they act across tools, data, and services. In this article, Veza argues that policy coverage is not keeping pace with that operational reality.

The gap is not just about AI adoption speed. It is about whether identity programmes still assume a stable human or workload model when the actor can initiate actions, request access, and operate across multiple systems under a governed identity boundary.

Key questions

Q: How should organisations govern AI agents alongside human identity and device access?

A: Organisations should treat AI agents as a separate identity class with their own entitlement boundaries, logging expectations, and approval model. Human IAM controls often assume interactive sign-in and review cycles, which do not fit autonomous or programmatic access. The safer approach is to define actor-specific policy and verify which access paths can be delegated without expanding trust unnecessarily.

Q: Why do AI agents make least privilege harder to enforce?

A: AI agents can move across multiple services, make autonomous decisions, and trigger several machine-to-machine actions in one task. That creates more opportunities for privilege creep, overuse, and lateral movement. Least privilege is harder when the system must authorise not only who is acting, but what the agent is doing right now.

Q: What breaks when AI agent access is reviewed only after the fact?

A: After-the-fact review leaves a gap between action and containment. If an agent can already reach a dataset, API, or SaaS system, the damage may be done before a human sees the alert. Runtime checks reduce that gap by stopping unauthorized actions before they execute.

Q: How do security teams know if agent governance is actually working?

A: It is working only if the team can answer three questions quickly for any agent: what it can reach, what it did recently, and whether that behaviour matches intent. If any of those answers require manual reconstruction, governance exists on paper but not in operations.

Technical breakdown

Why AI agents need identity governance, not just application security

AI agents sit in the control plane between policy and execution, which means they can inherit permissions, call tools, and move through systems in ways that traditional application security does not model well. Identity governance matters because the risk is not only what the model generates, but what the agent is allowed to do at runtime with access it can exercise across environments. If access review, authorisation, and privilege boundaries stop at deployment time, they miss the actual decision loop where agent behaviour creates exposure.

Practical implication: govern AI agents through identity controls that constrain runtime access, not only through model or application policy.

How least privilege changes when the identity is agentic

Least privilege for AI agents is not a static role design problem. It is a question of how much scope the agent needs for the shortest useful duration, across the smallest set of tools and datasets, with explicit boundaries on what it can invoke independently. The article’s signal is that agent identity security has to account for execution context, delegated access, and changing task scope, because the agent may touch far more systems than a single human operator would.

Practical implication: define agent permissions by task scope, data access, and tool boundary, then verify that those limits still hold in production.

What the updated OWASP Top 10 for LLM Applications signals for identity teams

The updated OWASP Top 10 for LLM Applications indicates that the industry is treating AI agents as a distinct security problem, not a side effect of generic AI use. That matters for identity teams because the control question becomes who or what is acting, what identity it uses, and how its privilege is governed across tool chains. In practice, this moves agent identity from an experimental concern into a governance subject with recurring review, policy, and monitoring requirements.

Practical implication: align identity governance, access monitoring, and policy enforcement around AI agents before they become embedded in business workflows.

Threat narrative

Attacker objective: The practical attacker objective is to exploit agent identity scope and access control weakness to reach data or systems that the original governance model did not intend to expose.

1. Entry occurs when an AI agent is given access to tools, data, or services under a governed identity that looks legitimate at provisioning time.
2. Escalation happens when the agent can use that access across multiple systems or tasks without governance keeping pace with its actual runtime behaviour.
3. Impact follows when overbroad or poorly scoped agent permissions create a security posture that outgrows the original policy assumptions.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity governance has become a first-order identity problem, not an adjacent AI risk. Veza’s 26% governance figure is less important than what it reveals about control maturity: most organisations are still treating AI policy as an overlay rather than an identity boundary. Once an agent can act through tools and services, the real question is who governs that actor across its full runtime lifecycle. Practitioners should treat AI agents as governed identities with explicit access scope.

Least privilege is being redefined by agent behaviour, not by provisioning convenience. Traditional IAM assumes that access can be assigned in a relatively stable way and then reviewed later. That assumption weakens when an AI agent can move across data, APIs, and workflow tools faster than review cycles or owner attestations can react. The practical conclusion is that privilege design for agents must start from bounded task execution, not from inherited operational convenience.

Authorisation is shifting from static policy enforcement to runtime identity control. The updated OWASP Top 10 for LLM Applications signals that the market is moving toward agent-centric risk analysis, which is where identity governance already needs to be. This is not just a tooling issue, because agent identity determines whether policy is actually enforceable once the system starts acting. Organisations that keep agent access outside their core identity programme will create a governance gap they cannot close later.

AI governance policy coverage and identity governance coverage are now the same conversation. A policy without enforceable identity boundaries does not meaningfully govern agent behaviour. That is why the CSA survey result matters to IAM leaders: it indicates that governance maturity is still lagging the operational reality of agentic systems. The implication is that identity teams must own the access side of AI policy, not merely support it.

Runtime access is the new control plane for agentic systems. The central concept here is runtime identity governance gap: the space between policy intent and the permissions an AI agent can actually exercise while working. That gap widens whenever access is broad, reviews are slow, or tool chains are loosely bounded. Practitioners need to close that gap as a core IAM design objective, not as a future enhancement.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Agentic AI Identity Guide

What this signals

Runtime identity governance gap: AI agent programmes fail when policy exists at approval time but not at execution time. That gap is becoming the main reason AI security and IAM have to be planned together, because the agent’s access decisions are what determine the blast radius of its actions.

Identity teams should expect governance demands to shift from static role assignment to continuous boundary enforcement. That means the practical question is no longer whether an agent is allowed to exist, but whether its access can be explained, reviewed, and constrained while it is actively doing work.

For practitioners

• Define agent identity ownership Assign a named business and technical owner for each AI agent identity, including approval authority, access boundaries, and review cadence.
• Bound agent permissions by task Limit AI agent access to the minimum tools, data sets, and systems needed for a specific workflow, rather than reusing broad service access.
• Move reviews to runtime controls Add access monitoring and policy checks that evaluate what an agent can do while it is active, not only what it was allowed to do at setup.
• Separate agent access from human approvals Avoid treating an AI agent as a proxy for a human user, because that hides the actual actor and weakens accountability for the permissions it uses.

Key takeaways

• AI agents are now being treated as governed identities, which pushes identity teams into the centre of AI security policy.
• The main risk is not the model alone, but the runtime access an agent can exercise across tools and services.
• Governance has to move from static provisioning logic to continuously enforced identity boundaries for agent behaviour.

Key terms

• Agentic Identity Governance: The discipline of managing, governing, and auditing the identities of autonomous AI agents across their full lifecycle, from provisioning with least-privilege credentials through continuous monitoring and decommissioning. An emerging sub-discipline of NHI governance.
• Runtime identity governance: Runtime identity governance is the discipline of checking identity behaviour while access is being used, not just when it is granted or reviewed. It combines telemetry, policy comparison, and response so organisations can detect when access drifts from intent across distributed systems.
• Agentic Least Privilege: A privilege model that limits an AI agent to the minimum tools, data, and services needed for a specific task. Unlike human role design, it must account for runtime scope changes, delegated access, and the fact that the agent may combine permissions across multiple systems in one session.

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 building or maturing an identity security programme, it is worth exploring.