NHI & AI
The Governance Vacuum Around AI and Non-Human Identity
A Cloud Security Alliance whitepaper finds non-human identities outnumber humans roughly 45 to 1, rising as high as 144 to 1 in cloud-native estates, while only about 15% of organisations feel highly confident they can prevent an NHI-based attack. AI agents make the gap qualitatively worse.
Key Finding
More than 16% of organisations do not track AI-identity creation at all. AI agents acquire permissions at runtime, spawn sub-agents, call external APIs, and write and execute code autonomously.
In May 2026 the Cloud Security Alliance's AI Safety Initiative published "The Non-Human Identity Governance Vacuum." The title is the finding. NHIs outnumber human identities by roughly 45 to 1, and as high as 144 to 1 in cloud-native environments, yet only around 15% of organisations report being highly confident in their ability to prevent an NHI-based attack. More than 16% do not track AI-identity creation at all.
The whitepaper's central argument is that AI agents are not just more service accounts. They are qualitatively new. A traditional non-human identity is static: a service account or API key is provisioned with a fixed scope and behaves predictably. An AI agent acquires permissions dynamically at runtime, can spawn sub-agents, invokes external APIs on its own initiative, and writes and executes code autonomously. The identity is no longer a fixed grant. It is an actor whose effective privilege changes as it runs.
That breaks the assumptions underneath most identity governance. Access reviews assume entitlements are reasonably stable between reviews. Least privilege assumes you can enumerate what an identity needs. Both assumptions fail when an agent can request new scopes mid-task and delegate to sub-agents that inherit or expand access. The "vacuum" the CSA names is the gap between governance designed for static identities and the runtime behaviour of agentic ones.
Our perspective: the confidence numbers and the tracking numbers are two views of the same root cause. You cannot be confident about preventing an attack against identities you are not even counting, and you cannot count identities that create themselves. The architectural response has to start before the agent runs, not after. That means agent identities are issued through a known broker rather than self-minted, sub-agent spawning is constrained and attributable to a parent identity, every external API call carries a scoped and short-lived credential, and the right to acquire new permissions at runtime is itself a governed permission. Until agent identity is designed as deliberately as workforce identity already is, the gap between 45 to 1 and 15% confidence will keep widening.
Need help with your identity architecture?
Every incident on this page was preventable with the right architecture. Let's talk about yours.
Book a Conversation