TL;DR: AI agent security treats agent access, visibility, and governance as an identity problem rather than a generic AI operations issue, with NHI and access-graph controls positioned as the organising layer, according to Veza. The practical takeaway is that IAM teams must distinguish agent behaviour from human workflows, because delegated access and unmanaged tool use quickly outgrow traditional review cycles.
NHIMG editorial — based on content published by Veza: Anthropic Project Glasswing and the Veza Access Graph: Two Pillars of the AI Security Era
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Veza’s analysis of AI agent security, access visibility, and NHI governance →
AI agent security and access governance: what changes for teams?
Explore further
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Veza’s AI agent security framing and what it means for IAM