Non-human identity: how to govern the machine actors on the systems you run

Last updated: 8 July 2026

TL;DR: A non-human identity is any credential a piece of software uses to act on a system: a service account, an API key, a token, a signing key, or an AI agent. They now outnumber people many times over, they are broadly permissioned, and they are barely watched. Governing them is the same discipline you already apply to human access, deliberately extended to the machines.

For every person in the average organisation there are, by CyberArk's 2025 count, 82 machine identities [3]. Other counts land lower or higher, from around 45 to 1 up to 144 to 1 in cloud-native estates [4], but the direction is not in dispute: the things authenticating to your systems are overwhelmingly not people. They are service accounts, API keys, tokens, signing keys, service principals, and, increasingly, AI agents that do not only read a system but act on it.

Almost every team governs its human logins with some care. Joiners are provisioned, leavers are offboarded, privileges are reviewed, and access is logged. The machine identities that outnumber them ten, fifty or a hundred to one usually get none of that. They are created in a hurry, granted broad rights so the integration works on the first try, handed a credential that never expires, and then forgotten. This article is the senior view of the whole problem: what a non-human identity is, why it became the bigger risk, and the disciplines that make one governable. It sits alongside our wider guide to securing software you built, inherited or self-host; here we go deep on the machine actors specifically.

What a non-human identity actually is

A non-human identity is the identity a piece of software uses to authenticate and act, without a person in the loop at the moment it acts. OWASP, the Open Worldwide Application Security Project, which maintains a dedicated Non-Human Identities Top 10, defines them plainly: non-human identities "are used to identify, authenticate, and authorize different software entities to access secured resources" [1].

The category is broader than most people picture. It covers the service account a backend uses to reach a database, the API key one system presents to another, the OAuth token an integration holds, the cryptographic signing key that mints authentication tokens, the cloud workload identity attached to a container, and the AI agent that holds a credential so it can restart a service or run a migration. What unites them is the property that makes them useful and dangerous in the same breath: they act on their own, at machine speed, using a credential rather than a person's judgement. When one is wrong, or stolen, there is no human hesitating at the keyboard.

Why non-human identities became the bigger risk

Three things turned a background detail into a front-line risk.

The first is scale. When machine identities outnumber people by 82 to 1 [3], or even 45 to 1 [4], the population you are not really governing is the large one. Every one of them is an account that can authenticate, and most were provisioned with more access than the task needed.

The second is that they are broadly permissioned and barely watched. OWASP is blunt about the pattern: non-human identities "are commonly granted very broad access to resources which leads to a widespread damage if compromised", and they "are notoriously under-monitored, allowing malicious activity to go unnoticed" [1]. Broad rights and thin monitoring is the exact combination you would design if you wanted a compromise to be both damaging and invisible.

The third is that their credentials leak at scale. A non-human identity's secret has to live somewhere: an environment file, a pipeline variable, a config store, a line of code. GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits during 2025 alone, a 34 percent increase year on year [5]. Each one is a machine credential sitting in the open, and a long-lived credential that leaks is worth just as much to whoever finds it as it is to the system that was meant to hold it.

This is not theoretical. In 2023 the threat actor Microsoft tracks as Storm-0558 "acquired an inactive MSA consumer signing key and used it to forge authentication tokens" to reach the email of roughly 25 organisations, including government agencies [6]. The breach did not begin with a phished password or an unpatched server. It began with a single compromised non-human credential, a signing key, that had enough reach to mint identities at will. That is the shape of the risk: not a person tricked, but a machine identity turned.

Zero Trust already treats a machine as an identity

The reassuring part is that the discipline for this is not new, and you do not have to invent it. The modern security model already anticipates machine actors as first-class identities. NIST, the United States National Institute of Standards and Technology, wrote non-person entities into its Zero Trust Architecture. Tenet four of NIST Special Publication 800-207 states that client identity "can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks" [7]. Its section on non-person entities goes further, noting that "artificial intelligence and other software-based agents are being deployed to manage security issues on enterprise networks" and need to interact with the system "sometimes in lieu of a human administrator" [7].

The UK's National Cyber Security Centre (NCSC) puts the same principle as a design rule. Under its Zero Trust design principles, a service "should have its own unique identity and be granted the minimum privileges necessary to function correctly" [10]. Read those two sources together and the standard is clear: a machine actor is an identity, it gets its own, and it gets the least privilege it needs. Most organisations already believe this about their people. Non-human identity governance is simply applying the belief to the machines, which is where the numbers, and therefore the risk, actually are.

The disciplines that make a non-human identity governable

None of what follows is exotic. It is least privilege, credential hygiene, lifecycle management and monitoring, the ordinary controls of identity security, pointed at a population most teams have never treated as identities at all. Five disciplines carry most of the weight.

Give each one its own identity. A machine actor should authenticate as itself, never as a person and never as a shared account reused across services. NIST names the control directly: IA-9, "Service Identification and Authentication", asks a system to "uniquely identify and authenticate" its services and applications before they communicate [8]. Its own identity is what makes everything else possible, from scoping its access to attributing its actions afterwards. When several services share one credential, or an agent borrows an engineer's login, you lose the ability to say who did what, which is why we treat proving what an agent did as a discipline in its own right.

Grant least privilege, scoped to the job. Give the identity the narrowest rights its task requires, and nothing it might want for some other task later. NIST's least-privilege control, AC-6, is written to include exactly these actors: it applies to "users (or processes acting on behalf of users)" [8]. A process acting on behalf of a user is precisely a service account or an agent. The default failure, an integration handed broad admin rights because that made it work immediately, is what turns a minor compromise into a major one.

Manage the secret, and make it short-lived. The credential a non-human identity holds is the thing that leaks, so it needs active management, not a one-time paste into a config file. NIST's authenticator-management control, IA-5, governs how these secrets are issued, protected and refreshed [8]. The NCSC is more pointed for automated actors: "avoid long-lived credentials", and "use temporary credentials where possible and revoke elevated access when tasks are complete" [9]. A credential that expires on its own is worth far less to whoever finds it than one that sits valid for years.

Own the lifecycle, and offboard on time. A non-human identity is created, and it must also be retired. The orphaned service account nobody remembers, the token from a decommissioned integration, the key belonging to a supplier you no longer use: these are standing doors with no one watching them. NIST's account-management control, AC-2, requires organisations to "create, enable, modify, disable, and remove accounts" across their lifecycle, and its "Disable Accounts" enhancement calls for disabling accounts that "are no longer associated with a user or individual" [8]. Machine identities need a joiners-and-leavers process exactly as people do.

Monitor, and keep the record. An identity you do not watch is the one OWASP warns goes unnoticed. Every non-human identity's activity should be logged as its own, in a record you can reconstruct after an incident. For AI agents this rises to a matter of accountability: NIST's AI Risk Management Framework names "accountable and transparent" as a property trustworthy AI must have, and holds that "trustworthy AI depends upon accountability" [11]. The record is what lets you answer the only question that matters after something goes wrong, which is what happened and who, or what, did it.

Those five disciplines map cleanly onto the risks OWASP catalogues. Its Non-Human Identities Top 10 for 2025 is the reference to work through when you are auditing your own estate [2]:

OWASP NHI risk (2025)	What it means	The discipline that addresses it
NHI1 Improper Offboarding	Machine identities left active after they are no longer needed	Own the lifecycle, offboard on time
NHI2 Secret Leakage	Credentials exposed in code, configs, logs or pipelines	Manage the secret
NHI3 Vulnerable Third-Party NHI	Identities held by suppliers and integrations you do not control	Least privilege, plus lifecycle for supplier access
NHI4 Insecure Authentication	Weak or outdated ways of authenticating machine actors	Give each its own identity, authenticated properly
NHI5 Overprivileged NHI	Machine identities granted far more access than the task needs	Least privilege, scoped to the job
NHI6 Insecure Cloud Deployment Configurations	Pipelines and deployments that expose or overreach identities	Least privilege and secret management in the pipeline
NHI7 Long-Lived Secrets	Credentials that never expire and never rotate	Make the secret short-lived
NHI8 Environment Isolation	Identities and secrets bleeding across environments	Scope identity and access per environment
NHI9 NHI Reuse	One identity or secret shared across many services	Give each its own identity
NHI10 Human Use of NHI	People borrowing a machine identity to act as themselves	Give each its own identity, monitor and keep the record

You do not need a new product to start on this. You need to apply controls you already understand to a population you have not been counting.

AI agents are the non-human identity you cannot ignore

Every non-human identity deserves this discipline, but the AI agent is the one forcing the issue, for two reasons.

It is the fastest-growing class of machine actor, and it is the most consequential, because an agent does not only hold a credential, it decides how to use it over many steps against systems that change underneath it. Worse, an agent can be steered by the content it reads. An instruction hidden in a web page, a ticket or a file can redirect what the agent does next, so an over-permissioned agent is not just a standing risk but a steerable one.

This is why the NCSC treats agent access as a deployment gate rather than a detail. Its guidance is to "give agents only the minimum access they need, for the shortest time required", and its readiness test is blunt: "if you cannot understand, monitor or contain an agent's actions, it is not ready for deployment" [9]. In practice that resolves into two companion pieces of work we cover in depth: granting an agent access you can take back, which is the scope-and-revoke half, and proving what an agent did, which is the record half. Both are non-human identity governance applied to the actor with the sharpest edges.

Who this matters most for

The stakes rise steeply when you run software or agents on systems you do not own. An agency, a managed-service provider, or a platform team operating on a client's estate carries the client's question as well as its own: what did your automation do inside our environment, and can you prove it. If your machine actors authenticated as shared accounts with standing credentials and thin logging, the honest answer is that you cannot fully say, and at that point the access was never really under control.

Governing non-human identities is what makes that question answerable. Each actor with its own scoped identity, a short-lived credential, a defined end of life, and a record of what it did, is the difference between a professional answer and an apology. For teams whose whole proposition is operating systems on behalf of others, that difference is the business.

Start with an inventory, not a rewrite

The instinct on reading all this is to reach for a rebuild. That is rarely the first move. You cannot govern what you cannot see, so the first move is to find the non-human identities you already have: the service accounts nobody owns, the API keys in old config, the tokens from integrations you have half-forgotten, the agent credentials someone issued for a proof of concept that quietly went to production. Almost every estate has more than its team expects, and the forgotten ones are the dangerous ones.

From that inventory the disciplines follow in order: give each actor its own identity, cut its privileges to what the task needs, bring its secret under management and shorten its life, define when it is retired, and make sure its activity is recorded. None of it requires a new category of tooling. It requires treating the machines that authenticate to your systems as identities, which they are, and governing them with the same seriousness you already give your people. Designed deliberately, before an incident, this is ordinary senior engineering. Reconstructed afterwards, from logs that were never meant to carry the weight, it is a very bad week.

Frequently asked questions

What is a non-human identity?

A non-human identity is any credential a piece of software uses to authenticate and act without a person in the loop: a service account, an API key, a token, a signing key, a cloud workload identity, or an AI agent. OWASP defines them as identities used "to identify, authenticate, and authorize different software entities to access secured resources" [1].

Why are non-human identities a security risk?

Because they combine scale, broad access and thin oversight. They outnumber human identities many times over, are commonly granted far more access than a task needs, and are, in OWASP's words, "notoriously under-monitored" [1]. Their credentials also leak at scale, so a single exposed key can give an attacker a broadly permissioned, unwatched way in.

How is a non-human identity different from a service account?

A service account is one kind of non-human identity. The term is the umbrella: it also covers API keys, OAuth tokens, signing keys, cloud workload identities, and AI agents. Treating them as one governable category, rather than separate technical details, is what lets you apply consistent identity, privilege and lifecycle controls across all of them.

Is an AI agent a non-human identity?

Yes, and it is the most demanding kind. An agent holds a credential and decides how to use it over many steps, and it can be steered by content it reads. NIST's Zero Trust guidance explicitly treats software agents as non-person entities that authenticate to systems [7], so an agent should get its own scoped identity, a short-lived credential, and a full record of its actions.

How do I manage non-human identities?

Start with an inventory, because you cannot govern what you cannot see. Then give each actor its own identity, grant least privilege scoped to its task, bring its secret under management and make it short-lived, define when it is retired, and log its activity as its own. These map to established NIST controls for account management, least privilege and authenticator management [8].

What is the OWASP Non-Human Identities Top 10?

It is a 2025 list from OWASP of the ten most significant risks specific to non-human identities, from improper offboarding and secret leakage to overprivileged and long-lived credentials [2]. It is a practical checklist for auditing your own estate, and it maps closely onto the governing disciplines of identity, least privilege, secret management, lifecycle and monitoring.

Govern the machines, not just the people

If machine identities outnumber your people many times over, then most of the access to your systems is held by actors you may not be governing at all. Bringing them under control, each with its own identity, least privilege, a managed and short-lived secret, a defined end of life, and a record of what it did, is the work we do on AI Agents and assess in a Vibe Code Audit. If you want a senior engineer to tell you honestly where your non-human identities stand before an incident finds them first, you can book an audit.

We are also building this into a product: a way to give people and AI agents governed access, scoped and revocable, with a sealed record of what they did, as one deliberate step rather than a stack of parts you wire together yourself. It is in early access with a small number of teams who manage servers and agents on behalf of others. If that is you, you can join the early-access list.

Related reading

• Securing software you built, inherited, or self-host: a senior guide
• Should you let an AI agent onto your servers? How to grant access you can take back
• AI agent audit trails: how to prove what an agent did on a system you manage
• OWASP Top 10 for LLM applications, in plain English

Sources

1. OWASP, "Non-Human Identities Top 10 (2025): Introduction". https://owasp.org/www-project-non-human-identities-top-10/2025/introduction/ (accessed 3 July 2026)
2. OWASP, "Non-Human Identities Top 10 (2025)". https://owasp.org/www-project-non-human-identities-top-10/2025/top-10-2025/ (accessed 3 July 2026)
3. CyberArk, "Machine Identities Outnumber Humans by More Than 80 to 1" (2025 Identity Security Landscape), 23 April 2025. https://www.cyberark.com/press/machine-identities-outnumber-humans-by-more-than-80-to-1-new-report-exposes-the-exponential-threats-of-fragmented-identity-security/ (accessed 3 July 2026)
4. Cloud Security Alliance, "Non-Human Identity and Agentic AI Governance" whitepaper. https://labs.cloudsecurityalliance.org/research/csa-whitepaper-nonhuman-identity-agentic-ai-governance-v1-cs/ (accessed 3 July 2026)
5. GitGuardian, "The State of Secrets Sprawl 2026", 17 March 2026. https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/ (accessed 3 July 2026)
6. Microsoft Security, "Analysis of Storm-0558 techniques for unauthorized email access", 14 July 2023. https://www.microsoft.com/en-us/security/blog/2023/07/14/analysis-of-storm-0558-techniques-for-unauthorized-email-access/ (accessed 3 July 2026)
7. NIST, "Zero Trust Architecture" (Special Publication 800-207), tenet 4 and section 5.7, August 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf (accessed 3 July 2026)
8. NIST, "Security and Privacy Controls for Information Systems and Organizations" (Special Publication 800-53 Revision 5), controls AC-2, AC-6, IA-5 and IA-9, September 2020. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf (accessed 3 July 2026)
9. National Cyber Security Centre, "Thinking carefully before adopting agentic AI", 15 May 2026. https://www.ncsc.gov.uk/blogs/thinking-carefully-before-adopting-agentic-ai (accessed 3 July 2026)
10. National Cyber Security Centre, "Zero trust architecture design principles: Know your user, service and device identities". https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles/know-your-user-service-device-identities (accessed 3 July 2026)
11. NIST, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)" (NIST AI 100-1), section 3.4, January 2023. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf (accessed 3 July 2026)