TL;DR: For every person in an organisation there are about 92 non-human identities, and 69% of organisations are concerned about attacks from them while only 15% feel confident preventing them, according to JumpCloud. The governance problem is no longer just volume but persistent, poorly owned machine access that IAM programmes were never built to control.
NHIMG editorial — based on content published by JumpCloud: non-human identity risk, AI agents, and the governance gap
By the numbers:
- For every person in an organisation, there are about 92 non-human identities.
- 69% of organisations are concerned about attacks from non-human identities.
- Only 15% feel confident in their ability to prevent them.
Questions worth separating out
Q: How should security teams govern non-human identities across cloud and DevOps environments?
A: Start with inventory, ownership, lifecycle control, and monitoring.
Q: Why do non-human identities increase lateral movement risk?
A: Because they often carry standing access into APIs, databases, pipelines, and cloud services.
Q: What breaks when machine identities have no formal owner?
A: Rotation slows, decommissioning is missed, and privileges accumulate over time.
Practitioner guidance
- Inventory every machine identity Map service accounts, API keys, certificates, tokens, workload identities, and automation scripts to a named owner and a business service.
- Separate machine lifecycle from human lifecycle Create joiner-mover-leaver processes for non-human identities so provisioning, rotation, review, and offboarding are explicit steps rather than side effects of application changes.
- Reduce standing privilege on automated access paths Replace broad or permanent machine permissions with scoped entitlements tied to the minimum systems required, and revalidate access whenever the workload or integration changes.
What's in the full article
JumpCloud's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific examples of how service accounts, API keys, certificates, and workload identities are used across common enterprise environments
- JumpCloud’s fuller breakdown of the visibility and monitoring problems that make machine identities hard to govern at scale
- More detail on the article’s AI agent distinction, including why autonomous behaviour changes the access model
- Practical discussion of the control and lifecycle challenges that arise when machine credentials are created automatically
👉 Read JumpCloud’s analysis of non-human identity risk and AI agent exposure →
NHI sprawl and autonomous agents: what IAM teams need to know?
Explore further
Non-human identity sprawl is now a governance failure, not just an inventory problem. The article’s most important point is that machine identities outnumber people by a wide margin and are often created faster than security teams can catalogue them. That is not merely operational noise. It is a structural weakness in IAM programme design, because unmanaged identities always become unmanaged access. Practitioners should treat discovery and ownership as core controls, not housekeeping.
A few things that frame the scale:
- Only 15% feel confident in their ability to prevent them, according to The State of Non-Human Identity Security.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
A question worth separating out:
Q: Who should be accountable for AI agent access decisions?
A: The organisation should assign accountability to the team that governs the agent’s intent, tool scope, and revocation path, not just the team that stores the credential. If an agent can make independent decisions, someone must own the behavioural boundary as well as the secret. Without that, governance stops at the token.
👉 Read our full editorial: Non-human identity sprawl is now the enterprise security blind spot