What Is a Non-Human Identity?

A non-human identity (NHI) is a digital actor — not a person — that can authenticate and be authorized to access enterprise resources. Service accounts, workloads, applications, API clients, automation and AI agents are all non-human identities. The credential it authenticates with — a secret, key, certificate or token — is not the identity itself. That distinction is the difference between governing identities and merely managing secrets.

A non-human identity is an actor, not a person

The most useful starting point is a standards definition rather than a vendor one. NIST's glossary defines a *non-person entity* as "an entity with a digital identity that acts in cyberspace, but is not a human actor" — a category that includes organizations, devices, and software or information artifacts. Non-human identity is the enterprise-security term for the same idea: an actor that operates digitally, can prove who it is, and can be granted access, without a person behind it in the moment.

Two properties matter. A non-human identity can authenticate — prove it is a particular actor — and it can be authorized — be granted permission to do something. The Cloud Security Alliance makes the same point in *Defining Non-Human Identity*: an entity qualifies as an NHI when it can be authorized to access resources. A script that never authenticates and is never granted access is automation, not an identity to be governed.

That framing already separates non-human identity from human identity. A person arrives through an HR system, has a manager, and follows a joiner-mover-leaver lifecycle. A non-human identity usually has none of that. It is created by an application team, a cloud deployment, a pipeline, an integration or an AI engineering effort — often with no owner, no review and no retirement date.

What counts as a non-human identity?

Non-human identity is an umbrella concept, not a single object type. In common enterprise usage it covers:

• Service accounts — one of the most familiar forms of non-human identity, used by software to authenticate without a person present.
• Workload identities — identities associated with running software or workloads. The SPIFFE project (CNCF) is a well-known standards effort in this space; in modern cloud environments these are frequently short-lived and context-derived, though that is a common characteristic rather than a universal rule.
• Application and API identities — the identity of an application or API client, often an OAuth client, frequently operating outside the view of the workforce identity program.
• Device identities — identities attached to physical or virtual devices.
• Automation and managed identities — pipeline, infrastructure-automation and platform-issued identities that act continuously.
• AI agents — a newer class discussed below.

These classes overlap, and they do not always map to a separate identity object in every system. "Non-human identity" is best understood as a governance concept that spans them, not a rigid technical hierarchy.

A related point of precision: in the taxonomy AVIKORE uses, and in common enterprise usage, *machine identity* is a subset of non-human identity — the persistent, often certificate- or hardware-linked cases — rather than a synonym for it. All machine identities are non-human identities; not every non-human identity is a machine.

A credential is not an identity

This is the distinction most enterprises get wrong, and it is where a definition earns its keep.

A credential is the material an identity uses to authenticate — a secret, an API key, a certificate, a token, an SSH key. The identity is the actor that credential represents and that the enterprise authorizes and holds accountable. They are not the same thing.

The Cloud Security Alliance draws the line explicitly in *Defining Non-Human Identity*: an API key is a credential an NHI may use, not the NHI itself; a certificate is a mechanism used to prove an identity, not the identity. The nuance is worth keeping intact — a token can carry authorization scope, and a certificate can convey attributes — but replacing or rotating that material does not change the actor it stands for. Rotate the secret, and it is still the same identity, with the same purpose, owner and access.

In the AVIKORE boundary model, the identities sit inside a governance boundary — with their purpose, owner, authority and lifecycle — and the credentials sit outside it, as the material used to authenticate. Vaulting and rotating secrets protects what is outside the boundary. It does not, on its own, tell you who owns the actor inside it, what that actor is for, or when it should cease to exist.

The practical consequence: an enterprise that has inventoried every secret but cannot say, for a given actor, *what uses this, what it is for, who owns it, what it may access, and when it should be retired* has credential visibility — not identity governance.

Why the distinction matters

Once the identity, not the credential, is the unit of governance, the questions that matter come into focus:

• Purpose — why does this actor exist? "Production account" is not a purpose.
• Owner — which accountable person or team can make decisions about it, and does that ownership survive personnel change?
• Authority — what can it actually do, in effect, not just in theory?
• Lifecycle — how is it created, reviewed, and — critically — retired?
• Accountability — who answers for what it does?

None of those are answered by a credential vault. They are answered by treating each material non-human identity as a governed actor. Managing credentials is necessary work. It is not the same as governing identities — and conflating the two is how organizations end up with strong secrets management and weak accountability at the same time.

Where AI agents fit

An AI agent can, technically, operate as a non-human identity: it authenticates and is authorized like any other actor. But agents introduce questions that ordinary service accounts do not — delegated authority, some degree of autonomy, and accountability for actions taken on a person's or system's behalf. The governing question shifts from "can this actor authenticate?" toward "what authority did we delegate, on whose behalf is it acting, and who owns the outcome?"

That is a distinct governance problem, and it deserves its own treatment rather than a paragraph here — see What Is Agentic Identity?.

What to understand next

Definition is the starting point. The harder enterprise questions build on it:

• Ownership. The single most common failure is that no one is accountable for a non-human identity. That is the subject of You Don't Have an NHI Tool Problem. You Have an Ownership Problem.
• Fitting NHIs into an existing program. Most enterprises already own the controls; the gap is the operating model that connects them. See Your IAM Program Was Designed for People.
• The direction of travel. Enterprise identity is moving from people to software to agents, and with it from access to authority. That evolution is the subject of Human → Non-Human → Agentic.

If you want a fast, private read on how your own program handles these questions, the NHI Executive Check is a six-question, browser-only diagnostic.

Research Sources

The definitions above are anchored to primary and neutral sources; vendor material is reviewed as market evidence, not endorsement.