Veza’s AI agent security framing and what it means for IAM

At a glance

What this is: This is Veza’s framing of AI agent security as an identity and access governance problem, with access visibility and control around agents and NHIs as the central issue.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams increasingly need one governance model that can handle service identities, AI agents, and human access without assuming they behave the same way.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Veza’s analysis of AI agent security, access visibility, and NHI governance

Context

AI agent security is fundamentally an identity governance problem, because the risk sits in what an agent can access, what it can call, and how well those permissions are governed across systems. The primary keyword here is AI agent security, and the governance question is whether existing identity controls can describe and constrain machine behaviour that acts outside human workflows.

Veza’s framing reflects a broader market shift: organisations are no longer just protecting service accounts or API keys, they are trying to govern software entities that can hold delegated access and operate across multiple tools. That makes access visibility, lifecycle control, and privilege review relevant to both agentic AI programmes and established NHI governance.

For teams that already struggle with service-account sprawl, this is not a new category of risk so much as a more dynamic version of an old one. The difference is that AI agents can amplify the blast radius of weak access design by selecting actions across systems at runtime, which makes graph-based visibility and policy enforcement more important than point-in-time review.

Key questions

Q: How should security teams handle delegated access when AI agents act on behalf of customers?

A: Security teams should treat delegated access as a separate governance layer, not as a normal login session. Define what the agent can do, how much value it can move, which approvals are required, and how delegation is revoked. Without those boundaries, the agent inherits more authority than the customer intended and fraud risk expands quickly.

Q: Why do AI agents complicate traditional IAM reviews?

A: Traditional IAM review assumes identities have human lifecycle events such as hire, role change, or offboarding. AI agents do not follow that pattern, so access can drift silently unless teams build continuous entitlement governance. Without that shift, reviews become retrospective paperwork instead of active risk reduction.

Q: What breaks when organisations audit AI agents like service accounts?

A: Audit trails break when teams record only the API call and ignore the prompts, tools, and model outputs that caused it. For AI agents, the explanation for an action is part of the evidence chain, and without it incident response cannot reliably reconstruct intent or accountability.

Q: Who should own agentic AI access risk inside the enterprise?

A: Ownership should sit jointly with IAM, security architecture, and the business team running the agent, because the risk spans identity, policy, and operational intent. If ownership sits only with the AI project team, access controls tend to weaken. If it sits only with IAM, the system context is usually missed.

Technical breakdown

Why AI agent access becomes an identity graph problem

AI agents rarely operate in isolation. They authenticate as one or more identities, inherit permissions from upstream systems, and then chain access across SaaS, cloud, and internal APIs. An access graph model helps teams understand not just who or what has access, but how that access can be traversed from one entitlement to another. For agents, that matters because the risky part is often not a single privilege but the combination of permissions across tool boundaries.

Practical implication: map agent identities to their full access graph before allowing them to operate beyond a single bounded workflow.

Why lifecycle governance matters for agentic and non-human identities

Identity lifecycle management for software entities is about provisioning, review, rotation, offboarding, and revocation. In practice, AI agents and other NHIs create governance debt when they are created quickly, granted broad access for development convenience, and then never fully retired. That produces the same failure pattern seen with service accounts: standing access persists long after the original need has changed, and review processes do not keep pace with deployment velocity.

Practical implication: tie every agent identity to an owner, expiry condition, and decommission path before it reaches production.

How access monitoring changes when the subject is an agent

Access monitoring for AI agents has to look beyond login events. Teams need to observe tool invocation, access path changes, privilege escalation, and unusual delegation patterns. The important distinction is that an agent may behave correctly at authentication time and still become risky later by calling a broader set of tools than intended. That is why monitoring must track runtime access behaviour, not just whether an identity successfully signed in.

Practical implication: monitor agent runtime behaviour and privilege drift, not only authentication success or failure.

NHI Mgmt Group analysis

AI agent security is now an extension of NHI governance, not a separate discipline. The same weaknesses that make service accounts risky, including broad entitlements, poor visibility, and weak lifecycle control, become more consequential when the identity can invoke tools dynamically. The difference is behavioural, not just technological, and practitioners should treat agent identities as governed machine identities first.

Access graph thinking is becoming the only workable way to reason about agentic permissions. Point-in-time entitlement lists are too shallow when an agent can chain access across systems. A graph model exposes where one credential, token, or delegated permission creates reach into another environment, which is where the practical blast radius lives.

Lifecycle debt is the named concept practitioners should track here. That debt accrues when AI agents are provisioned faster than they are reviewed, constrained, and removed. The problem is not just excess access, it is the compounding effect of unmanaged creation and retirement across agent and NHI populations, which pushes governance out of sync with deployment speed.

Human IAM controls do not disappear, but they stop being sufficient as the primary control plane. Approval workflows, recertification cadences, and role assignments still matter, yet they were designed around stable human operators. When software identities can act continuously and at scale, the governance centre of gravity moves toward ownership, scope, and runtime observation.

The market is converging on unified identity control across humans, NHIs, and AI agents. That is a rational response to the fact that the same platform now has to explain access across all three actor types. Practitioners should expect more consolidation around access visibility, governance, and monitoring because fragmented identity tooling cannot keep pace with mixed identity estates.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• From our research: 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
• For teams formalising agent governance, NHI Lifecycle Management Guide shows why provisioning, rotation, and offboarding need one control model, not three separate workflows.

What this signals

Lifecycle governance will become the deciding control for mixed identity estates. As AI agents are added to NHI-heavy environments, the hardest problem is no longer only visibility, it is keeping ownership, review, and removal aligned with how fast identities are created. With 92% of organisations exposing NHIs to third parties, per the Ultimate Guide to NHIs, the same governance gap will surface in agent ecosystems if lifecycle controls remain human-paced.

Access graph coverage will matter more than individual entitlement reviews. Teams that cannot trace how an identity reaches data, tools, and downstream systems will not be able to explain agent risk with enough precision for IGA or PAM decisions. The practical shift is toward runtime visibility across the whole chain, not isolated access snapshots.

Identity blast radius becomes the useful way to discuss AI agent risk. That concept captures how a single delegated identity can expand across tools once runtime behaviour begins. Security leaders should expect board-level questions about where that blast radius is largest, which identities are orphaned, and which workflows still depend on standing access.

For practitioners

• Define agent identity ownership Assign a named business and technical owner to every AI agent identity, including a retirement path and review cadence before production use.
• Inventory delegated access paths Map every token, service account, and downstream API the agent can reach so you can see where one permission expands into another system.
• Restrict runtime tool scope Limit each agent to the smallest tool set needed for its current task and remove broad cross-system access by default.
• Add runtime monitoring for privilege drift Track tool calls, access path changes, and delegation anomalies so review is based on actual behaviour rather than static entitlement records.
• Build offboarding into agent lifecycle Revoke credentials, remove downstream grants, and verify teardown when the agent is replaced, retired, or no longer needed.

Key takeaways

• AI agent security is best understood as a governed identity problem, with runtime access and lifecycle control at the centre.
• Static entitlement review is not enough when an agent can chain access across tools and expand its own effective permissions.
• Enterprises need one lifecycle model for humans, NHIs, and agents if they want visibility, ownership, and offboarding to hold together.

Key terms

• Access Graph: An access graph is a relationship model that links identities, permissions, data objects, and system interactions. In NHI governance, it helps security teams see the full path from an agent or user to the action it can take, which is more useful than isolated account reviews.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Lifecycle Debt: Lifecycle debt is the accumulation of access and ownership problems when tools, credentials, or integrations outlive the business context that created them. In MCP programmes, it appears when servers remain active after teams change, systems retire, or approvals are forgotten.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• How Veza models agent access through its access graph and where that model differs from simple entitlement reporting
• Specific product terminology and platform navigation for Access AI, Access Agents, and NHI Security
• Operational examples of how visibility and monitoring are applied across agent and non-human identities
• The source's broader product context for teams evaluating identity security platform features

👉 Veza’s full article covers the platform framing and operational context behind its AI agent security approach.

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 identity governance maturity across humans, NHIs, and AI agents, it is worth exploring.