Non-Human Identity Security: A Guide to Machine Governance

Key Takeaways:

• Non-human identities (service accounts, workloads, bots, pipelines, and AI agents) now outnumber human ones by more than 80 to 1, and most teams can’t say how many they have.
• Unlike people, NHIs don’t log out, can’t use MFA, and are rarely retired, so one stolen credential can quietly expose a large slice of your environment.
• Six risks show up again and again: Exposed secrets, over-privileged access, orphaned identities, no clear owner, no inventory, and ungoverned AI agents.
• A practical governance framework (continuous inventory, ownership, least privilege, rotation, monitoring, and Zero Trust) cuts NHI risk without slowing your automation down.
• Agentic AI is the fastest-growing NHI category, and most governance programs weren’t built for autonomous identities that act on their own.

A non-human identity (NHI) is any digital identity that belongs to software rather than a person. These are the automated actors in your environment, the service accounts, workloads, RPA bots, CI/CD pipelines, and AI agents that authenticate and take action without a human driving each step. Each one relies on credentials such as API keys, tokens, certificates, or passwords to prove who it is, and any actor can use any of these credential types.

Here’s the problem. These identities have quietly become the largest population in your environment. KPMG’s Cybersecurity Considerations 2026 report puts the NHI-to-human ratio at more than 80 to 1 in the average enterprise, and machine identities in the average enterprise jumped from roughly 50,000 in 2021 to 250,000 in 2025. They’re also the least governed. Most organizations can’t tell you how many NHIs they have, what those identities can reach, or when anyone last reviewed them.

That gap is where the risk lives. This guide breaks down the full landscape: What NHIs are, the specific ways they get exploited, a governance framework you can actually put to work, and what changes now that AI agents are in the mix.

Why Non-Human Identity Security Matters

Non-human identities matter because they’ve become the largest and least-watched attack surface in the enterprise. They run quietly in the background, they hold real access, and most security programs were built to watch people, not machines.

Part of the problem is that NHIs behave nothing like human identities:

• They can’t prove who they are the way people can. There’s no face ID or fingerprint for a piece of software, so telling a legitimate process apart from a malicious one is genuinely hard.
• They don’t log out or take breaks. A service account runs until something stops it, so there’s no natural end to a session and no obvious moment when access should be revoked.
• They can’t use MFA, and they’re rarely retired. Once created, most NHIs stay active long after anyone remembers why, which leaves them persistent and unguarded.

The blast radius is what makes this urgent. Machine identities don’t just outnumber human ones, they tend to hold broad, standing access that no human account would be granted, so a single stolen token or service account can hand an attacker far more than one application. Credentials are already the soft underbelly of enterprise security: The Verizon Data Breach Investigations Report found that stolen credentials were still the most common initial access vector, used in 22% of breaches, and that 88% of basic web application attacks involved stolen credentials. Non-human credentials specifically are now prime targets, with SpyCloud recapturing 18.1 million exposed API keys and tokens in 2025 alone.

It isn’t only attackers, either. Autonomous software can do damage by mistake. An over-permissioned identity running the wrong action quickly is its own kind of incident, no bad actor required.

Regulators are catching up. Frameworks like SOC 2 and ISO 27001, along with Zero Trust architectures, increasingly expect documented governance of machine identities, not just human ones. For more on why identity belongs at the center of resilience, see Veeam’s take on identity-first resilience.

Types of Non-Human Identities

NHIs come in two layers that are easy to conflate but worth separating: The actors that do the work, and the credentials they use to authenticate. Any actor can use any credential type, which is part of what makes them hard to govern.

The actors (what acts):

• Service accounts — identities created so applications and processes can talk to systems, often over-permissioned at setup.
• Application and workload identities — tied to VMs, containers, and serverless functions that spin up and disappear in seconds.
• RPA bots — automation that needs privileged access to sensitive systems and rarely has a human supervisor.
• CI/CD pipeline identities — used by tools like Terraform, Kubernetes, and Ansible to provision and deploy, often without security oversight.
• AI agents — the newest and fastest-growing actor, accessing data and calling APIs on their own.

The credentials they use (how they authenticate):

• API keys and tokens — the most commonly exposed credential type; frequently hardcoded or committed to version control.
• OAuth and access tokens — grant persistent access that often outlives the integration that created it.
• Certificates and SSH keys — machine-to-machine trust that’s powerful and easy to lose track of.
• Passwords — still used by many service accounts, and the hardest to rotate at scale.

One actor often holds several credentials, and the same credential can be shared across many actors, which is exactly why a single exposed key can have such a wide blast radius.

Among these actors, one distinction shapes how you govern them. Traditional bots and workloads are deterministic: The same code runs the same way every time, so you can predict and measure exactly what they’ll do.

On the other hand, AI agents are non-deterministic. Ask one to analyze the same data ten times and you can get a slightly different result each time, because the behavior is probabilistic rather than fixed.

That difference matters for security. With a deterministic workload, you can define exactly what “normal” looks like. With an autonomous agent, normal is a moving target, which makes scoping its access and spotting misuse much harder. We’ll come back to this when we get to governance in the age of AI.

Top Non-Human Identity Security Risks

Most NHI incidents trace back to one of six recurring risks, and they tend to compound: A single exposed credential becomes far more dangerous when the identity behind it is over-privileged, unowned, and unmonitored.

Credential Exposure and Secrets Sprawl

NHIs authenticate with secrets, API keys, tokens, certificates, and passwords, and those secrets have a habit of spreading. They get hardcoded into source, baked into container images, passed through CI/CD pipelines, and written to logs. From there they leak further, into config files, ticketing systems, wikis, and chat threads where no security tool is watching. This scattering is what “secrets sprawl” describes, and it’s nearly impossible to track by hand. The danger is concentration of access: A single exposed key often unlocks a production system or cloud account, giving an attacker a foothold to pivot across the environment from one discovered credential.

Over-Privileged Access

Over-privileged access is a separate problem from exposure. In this case, the issue isn’t that a credential leaked, it’s that the identity was allowed to do far more than its job requires. NHIs are routinely granted broad permissions during setup, because wide access is the fastest way to get an integration working, and those permissions are rarely revisited once things are running. Unlike a departing employee, a service account has no natural trigger that prompts anyone to scale its access back. The result is a population of identities that can read, write, and delete well beyond their actual purpose. That makes them a primary driver of lateral movement: Once an over-privileged account is compromised, the attacker inherits everything it can reach. Veeam covers this pattern in more depth in its guide to identity management vulnerabilities and attacks.

Stale and Orphaned Identities

Orphaned NHIs are credentials that stay active after the system, project, or employee they were created for is gone. They accumulate quietly: A contractor offboards, a project wraps, a service is decommissioned, but the identity it relied on is never revoked. These identities are dangerous precisely because no one is watching them anymore. They still hold valid access, yet they’ve fallen off everyone’s radar, so unusual activity on a long-forgotten service account rarely sets off an alarm. To an attacker, an orphaned identity with live credentials and no owner is close to an ideal target.

No Ownership, No Accountability

The most common NHI governance failure is organizational, not technical. When an identity has no assigned human owner, no one is responsible for rotating its credentials, reviewing its permissions, or acting when something looks wrong. Ownership is the thread that ties an NHI back to a person who understands what it’s for and what it should be allowed to do. Without that thread, even a clearly identified risk has no clear path to remediation, because there’s no one accountable for fixing it. Governance programs that skip ownership tend to stall here.

Lack of Visibility and Inventory

You can’t govern what you can’t see, and most organizations simply can’t see all of their NHIs. They lack a complete, current inventory of which identities exist, what created them, and what each one can access. That blind spot undermines everything downstream: You can’t enforce least privilege on identities you haven’t catalogued, and you can’t rotate credentials you don’t know about. It also cripples incident response. When a service account is compromised, teams that lack an inventory often can’t determine what the identity could reach or what it actually did, which turns a contained problem into a drawn-out investigation.

AI Agent Access Without Governance

This is the newest and fastest-growing risk in the category. AI agents are being granted access to enterprise data, applications, and APIs so they can act autonomously, and that access is frequently handed over with little governance attached. The connective tissue makes it riskier: Emerging standards for linking agents to tools and data, such as the Model Context Protocol, were designed for capability and ease of integration first, and often don’t enable authentication or access controls by default. An AI agent’s credentials carry the same risks as any other NHI, but the blast radius is larger, because a single agent may reach across dozens of systems on its own and act in ways no one explicitly approved. Veeam explores this shift in its piece on access plane security and identity protection.

Non-Human Identity Security Best Practices

Here’s the operational side: A governance framework that security leaders and cloud architects can put to work without slowing automation down. None of these steps require you to stop shipping. They require you to make NHIs visible, accountable, and scoped. Work through them in order.

Inventory Your NHI Actors

Governance starts with discovery. Keep a continuous, real-time record of the workloads, pipelines, bots, agents, and service accounts operating in your environment: What each one is, what it was created for, who owns it, and what it can access. The key word is continuous. NHIs are created constantly in cloud and DevOps environments, where a single engineer can now spin up 100 agents in an afternoon. A static spreadsheet is out of date within days.

Map the Credentials Each NHI Uses

Inventorying the actors is only half the picture. For every NHI, track which credential mechanisms it authenticates with (such as API keys, tokens, certificates, or passwords), where those secrets live, and when each was last rotated. Because one credential can be shared across several actors, this mapping is what tells you the true blast radius if a secret is exposed.

Assign a Human Owner to Every NHI

Every NHI needs a named human owner responsible for rotation, permission reviews, and incident response. This is the fix for the accountability gap. Without clear ownership, even a perfectly inventoried identity becomes a dead end the moment something goes wrong, because there’s no one accountable for acting on it.

Apply Least Privilege to Every NHI

Scope every service account, API key, and agent credential to the minimum access its job requires, then revalidate on a set schedule. Least privilege is harder for NHIs than for people, because there’s no obvious owner and no natural offboarding trigger to prompt a review. That’s exactly why it has to be a deliberate, systematized process rather than a one-time setup decision.

Rotate and Expire Credentials Regularly

Static, long-lived credentials are one of the biggest NHI risks. A compromised key that never expires gives an attacker indefinite access, yet Entro found that 71% of NHIs aren’t rotated within recommended timeframes. Automated rotation is the standard to aim for. It has to be a system-enforced policy, not a manual chore that depends on someone remembering to do it.

Monitor NHI Activity for Anomalies

Give every NHI a behavioral baseline, then flag the deviations: access to new resources, unusual API call volumes, off-hours activity. As one practitioner put it, the place to start is solid logging, monitoring, and auditing around your agents and automated workflows, backed by real alerting and dashboards. Bear in mind that tools tuned for human behavior will miss machine threats, so this usually means purpose-built configuration in your existing SIEM or UEBA platform. Veeam’s identity and access management guide goes deeper here.

Extend Zero Trust Principles to NHIs

Zero Trust, “never trust, always verify,” applies to machines just as much as people. This is the part teams most often confuse with least privilege, so it’s worth being precise: Least privilege limits what an identity can do, while Zero Trust means every system independently verifies the identity on every request rather than trusting one upstream check. Pair it with just-in-time access, which grants permissions only when needed, only for as long as needed, and then revokes them automatically.

Non-Human Identity Governance in the Age of AI

Agentic AI has fundamentally expanded the NHI problem. AI agents are autonomous identities that access, process, and transmit enterprise data without a human approving each step, and that autonomy is exactly what makes them hard to govern.

Go back to the deterministic versus non-deterministic distinction. A traditional workload does the same measurable thing every time. An AI agent doesn’t. It can reach a different result on the same data from one run to the next, and it can act on its own, which means there’s no human in the loop to catch it doing the wrong thing. That’s the extra layer of risk that autonomy introduces.

Most NHI governance frameworks weren’t built with this in mind. Traditional IAM tools track users and service accounts, not the dynamic, multi-system access patterns an AI workload generates. The fix isn’t a separate program. It’s extending the same discipline you already apply to service accounts, scoped permissions, behavioral monitoring, credential rotation, and human ownership, to every AI agent you run.

Governance, in practical terms, comes down to oversight: being able to say what the AI did, decide whether it did the right thing, and step in when it didn’t. That gets sharper with LLMs. When a model is granted access to sensitive data as part of its job, that access has to be governed like any other privileged credential. Before you connect a model to sensitive data, security teams need clear answers to three questions:

• Who authorized this access, and is that decision documented and reviewable?
• What data can the model actually reach, and is that scope as narrow as the task requires?
• What happens if the model is manipulated or compromised, and how would you know?

It’s not a hypothetical concern, given that the Model Context Protocol now standardizing agent access ships with no authentication enabled by default.

How Veeam Supports Non-Human Identity Security

Strong NHI governance lowers the odds of a compromise. It doesn’t reduce them to zero. Credentials still leak, agents still misfire, and as we covered earlier, plenty of NHI incidents come from honest mistakes rather than attackers. When that happens, your ability to recover clean data quickly is the last line of defense, and that’s where Veeam fits.

Veeam approaches the problem through Zero Trust Data Resilience (ZTDR), a model developed with Numberline Security that extends Zero Trust principles to backup and recovery, the layer most identity programs overlook. The same ideas that govern NHIs apply here: least-privilege access, assume breach, and shrink the blast radius. ZTDR does it by separating backup software from storage into isolated resilience zones and keeping backups immutable, so a compromised identity, human or non-human, can’t quietly reach in and destroy your means of recovery.

Identity controls and data resilience work best together. Governance reduces how often something goes wrong; resilient, recoverable data limits the damage when it does.

Learn how to gain deeper visibility into data and AI risks in the Data Trust and Resilience Report 2026.

FAQs