Why non-human identities are becoming a governance problem

At a glance

What this is: This is an editorial analysis of why non-human identities have become a mainstream security concern, driven by scale, automation, AI, and attacker interest.

Why it matters: IAM and NHI teams need to treat service accounts, machine identities, and AI-driven access as a governance population, not a side effect of infrastructure.

By the numbers:

• Non-human identities are currently averaging a 50:1 ratio against their human counterparts, and that gap is projected to widen to as much as 100:1.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, making organisations failing to scope AI access properly 4.5x more likely to experience a security incident.

👉 Read One Identity's post on why non-human identities are suddenly a big deal

Context

Non-human identity sprawl is not a new phenomenon. Service accounts, machine identities, tokens, certificates, and automation accounts have existed for years, but they were often treated as infrastructure plumbing rather than governed identities. That is now a problem for IAM because the growth of AI and software defined infrastructure has pushed these identities into the main security path.

The practical issue is governance, not naming. Once non-human identities outnumber human users by orders of magnitude, teams lose reliable ownership, review, and privilege scoping. That is the same failure mode highlighted in the NHI Lifecycle Management Guide, where identity lifecycle visibility and rotation are what keep machine access from becoming permanent access.

Key questions

Q: Why do non-human identities create more governance risk than human users?

A: Non-human identities create more governance risk because they are numerous, machine-speed, and often long-lived. They are frequently tied to scripts, pipelines, and automation rather than named owners. That makes ownership, review, and revocation harder, especially when credentials are copied or reused across environments.

Q: How should security teams govern non-human identities at scale?

A: Security teams should govern non-human identities with the same discipline used for human identities, but adapted for automation. That means assigning owners, scoping privilege tightly, setting expiry and rotation rules, and reviewing access by workload or pipeline instead of by user account alone.

Q: What is the difference between service accounts and non-human identities?

A: Service accounts are one type of non-human identity, but the broader category also includes API keys, tokens, certificates, bots, workloads, and AI agents. The practical difference is governance scope. Teams need controls that cover every machine identity, not just traditional service accounts.

Q: When should organisations treat machine access as a high-risk identity problem?

A: Organisations should treat machine access as high risk whenever the credential can reach production systems, automate privileged tasks, or be reused across environments. That threshold is often lower than teams expect because non-human access can scale silently and bypass human review cycles.

Technical breakdown

Why NHI sprawl changes identity risk

Non-human identities differ from human users because they are created for speed, automation, and machine-to-machine trust. That means they are often long-lived, heavily privileged, and poorly tied to a single owner or business process. As the count rises, the problem is no longer just inventory. It becomes classification, lifecycle state, and privilege drift. A service account that is harmless in one workflow can become a control gap when copied into another system or left active after the workload changes. Practical implication: track ownership, purpose, expiry, and privilege for every NHI as part of the identity record.

Practical implication: Inventory is necessary, but lifecycle governance and ownership are what prevent hidden access from persisting.

How AI and automation expand the NHI attack surface

AI systems and automation platforms introduce more execution points that need credentials, tokens, or delegated authority. In practice, each tool, pipeline, or agent can inherit access that exceeds the minimum needed for the task. The risk is not just compromise of a single secret. It is that machine identities can chain across systems faster than human review cycles can detect. That is why NHI security must be designed around credential scoping, short-lived access, and policy enforcement at runtime. Practical implication: treat every automation path as an access path, not just an operational workflow.

Practical implication: Design credential scope and runtime policy for machine actions before scaling automation.

What makes over-privileged machine access so hard to contain

Over-privileged NHI access tends to persist because it is embedded in scripts, CI/CD jobs, service configurations, and infrastructure code. These access paths are rarely revisited with the same discipline applied to employee access reviews. When a workload is cloned or repurposed, inherited privileges often follow it. The result is access accumulation, which is a core NHI governance failure. Standard IAM review cycles miss this when they focus on human roles instead of machine dependencies. Practical implication: align access reviews to workloads, pipelines, and certificates, not only to user directories.

Practical implication: Review the workload, not just the account, when checking entitlement creep.

Threat narrative

Attacker objective: The attacker wants durable, trusted access that blends into automation and can be used to reach multiple systems without raising immediate suspicion.

1. Entry occurs through exposed or reused machine credentials, often in automation pipelines or scripts.
2. Escalation follows when the compromised identity has broader access than the task requires, allowing the attacker to move into adjacent systems.
3. Impact is achieved by using trusted non-human access to persist, exfiltrate data, or disrupt infrastructure at machine speed.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Non-human identity growth is now a governance problem, not a taxonomy debate. The important question is no longer whether an account is called a service account, token, or agent. The question is whether it is owned, scoped, rotated, and reviewed like any other identity with access to production systems. NHI programs that stay stuck in naming conventions will miss the operational risk. Practitioners should treat identity governance as the control plane for machine access.

Identity blast radius is the right way to think about NHI risk. When a machine identity is copied, reused, or left active after its original purpose changes, the impact is not isolated. It multiplies across workloads, pipelines, and linked systems. That makes blast radius, not just credential secrecy, the decisive control variable. Teams should measure where a single NHI can reach before they measure how many they have.

AI makes existing NHI weaknesses visible faster, not safer. The article is right to separate AI from the whole problem, because the underlying issue is broader automation. But AI raises the stakes by increasing the number of delegated actions and the speed of trust decisions. That pushes IAM teams toward continuous controls, shorter credential lifetimes, and better policy boundaries. Practitioners should assume automation will amplify whatever governance model already exists.

Static trust models do not scale when NHIs become the majority population. A model built around periodic reviews and durable secrets cannot keep pace when machine identities expand faster than human oversight. The discipline now needs lifecycle controls, privilege scoping, and inventory accuracy as baseline requirements. Organisations that do not rework those controls will keep discovering NHI risk only after an incident.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• For a broader lifecycle lens, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns that apply to machine identities and agents.

What this signals

Identity blast radius is becoming the operational metric that matters most, because the question is no longer how many NHIs exist but how far each one can move if trust breaks. With 69% of security leaders saying identity management must fundamentally shift to address agentic AI systems, the governance model is already being pulled toward machine-first controls. Teams should prepare for identity review processes that are tied to runtime behaviour, not calendar cycles.

The control challenge is widening faster than most programmes can absorb. The 2026 Infrastructure Identity Survey found that only 13% of organisations feel extremely prepared for agentic AI, which means most teams are scaling into a confidence gap rather than closing one. That gap is where policy drift, static credentials, and overlooked service accounts become persistent exposure.

For practitioners, the next step is to align NHI governance with the broader identity stack, including Zero Trust and lifecycle management. The practical standard is not perfect visibility on day one, but enough policy, ownership, and rotation discipline to stop machine access from becoming permanent access. That is where the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0 become useful anchors for programme design.

For practitioners

• Build a complete NHI inventory Map service accounts, API keys, tokens, certificates, automation accounts, and AI agents to owners, workloads, and expiry dates. Include where each identity is used and what systems it can reach.
• Reduce standing privilege for machine access Replace durable credentials with short-lived access where possible, and enforce least privilege for each workflow rather than each system. Revalidate every non-human identity that can reach production.
• Tie access reviews to workloads and pipelines Review non-human access by application, CI/CD job, or infrastructure process so inherited permissions are not missed. This is where dormant access and privilege creep usually hide.
• Track credential rotation as a governance control Set rotation and expiry rules for secrets, certificates, and tokens, then verify that the runtime environment actually honours them. If rotation is manual, treat that as a residual risk.

Key takeaways

• Non-human identity growth is turning machine access into a core IAM governance issue, not an edge-case operational task.
• AI and automation magnify existing NHI weaknesses by expanding delegated access faster than review cycles can keep up.
• Teams should focus on ownership, privilege scope, and lifecycle control to reduce the blast radius of machine identities.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, infrastructure, or automation instead of a person. It includes service accounts, API keys, tokens, certificates, bots, workloads, and AI agents that authenticate, request access, or perform actions in systems.
• Identity Blast Radius: Identity blast radius is the amount of damage a compromised identity can cause before it is contained. For non-human identities, it is determined by privilege scope, reuse, runtime reach, and how widely a credential can move across systems or environments.
• Standing Privilege: Standing privilege is access that remains available all the time instead of being granted only when needed. In NHI environments, standing privilege usually appears in durable secrets, persistent service account permissions, and long-lived tokens that outlast the task they were created for.
• NHI Lifecycle Governance: NHI lifecycle governance is the practice of controlling creation, use, rotation, review, and removal of machine identities. It is the operational layer that keeps automation from accumulating hidden access, stale credentials, and unowned accounts over time.

Deepen your knowledge

NHI lifecycle governance and machine access scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring service accounts, tokens, and AI agents under one control model, this is a useful starting point.

This post draws on content published by One Identity: Why are non-human identities suddenly such a big deal? Read the original.