What is a non-human identity (NHI)?

Identity or credential: the distinction that matters

Much of the industry blurs this line. Some vendor glossaries define NHIs as "access credentials" that "come in the form of API keys, OAuth tokens, service accounts, and secrets." That conflation is convenient for tools that scan for secrets, but it is wrong, and it leads teams to the wrong fixes.

An identity is an actor: something that can be authenticated, authorized, held to a policy, and audited. A credential is an artifact that actor presents to prove who it is. One NHI often holds many credentials at once (a key, a token, a certificate), and credentials rotate while the identity persists.

The distinction changes what you do about risk. Rotating a leaked key treats the symptom; the identity keeps every permission it had. Deleting a secret from a repo does not deprovision the service account that used it. If you only manage credentials, you are managing evidence of identities, not the identities themselves.

What counts as a non-human identity?

Any software actor that authenticates to another system qualifies. The common populations:

• Service accounts: long-lived accounts that applications use to reach databases, queues, and APIs
• Workload identities: pods, VMs, containers, and serverless functions asserting who they are to cloud platforms
• CI/CD pipelines: build and deploy jobs holding credentials to source control, registries, and production
• Bots and RPA: automation that acts inside SaaS tools, often installed once and forgotten
• Third-party OAuth integrations: external apps granted standing access to your data
• AI agents: LLM-driven actors that choose their own actions at runtime, the newest and fastest-growing population

How many NHIs does an enterprise have?

Estimates vary by methodology, but every study points the same direction: non-human actors are the large majority of identities, and the ratio is widening as AI adoption accelerates. Treat the specific numbers as reported ranges, not precise counts.

Why AI agents are the newest NHI population

Classic NHIs are deterministic: a cron job does the same thing every night, so its identity can be scoped once and reviewed annually. AI agents break that assumption. An agent decides at runtime which tools to call, which credentials to exercise, and which systems to touch, and its behavior varies with every prompt.

Agents also chain identity in ways older NHIs never did. An agent acting on behalf of a user, calling a tool server, which calls an API with a service account, creates a delegation chain where the effective actor is ambiguous unless each hop carries identity. That chain is where most current inventories go blind. For why this population changes the whole identity model, see The Non-Human Majority.

Why NHIs are harder to secure than human identities

Human identity has decades of tooling: SSO, MFA, joiner-mover-leaver lifecycle, session timeouts. Almost none of it transfers to NHIs.

The gap most definitions skip is runtime. An NHI's risk is not what its inventory entry says; it is what its live sessions actually do. A service account that is dormant for a year and then starts exporting a database has not changed in any registry, only in its running behavior. Inventory answers what exists; only session-level observation answers what is happening.

• No MFA: an NHI cannot approve a push notification, so a stolen credential is usually sufficient
• No natural lifecycle: NHIs have no offboarding date, so they accumulate for years after their purpose ends
• Ownership ambiguity: the engineer who created the account leaves, and nobody remaining can say what it is for
• Long-lived, overprivileged credentials: keys scoped broadly at creation and never narrowed
• No session visibility: most tools inventory NHIs at rest and never observe what they do at runtime

How do you secure non-human identities?

The practices that work follow directly from treating NHIs as actors rather than keys:

• Inventory every NHI and bind each one to a human owner and a stated purpose
• Enforce least privilege per identity, not per credential, so rotation never silently restores broad access
• Prefer short-lived, workload-issued credentials over static secrets wherever the platform allows
• Decommission NHIs on a lifecycle, the way you offboard employees
• Monitor sessions at runtime and alert on behavior that deviates from the identity's established purpose

What does an NHI compromise look like in practice?

The following walkthrough is hypothetical, a composite of patterns that recur across published incident writeups rather than a single named breach. A data platform team creates a service account, etl-prod, with read access to the warehouse and write access to a storage bucket. An engineer embeds its key in a helper script to unblock a migration, the script lands in a repository, and the key sits there for two years. The engineer leaves. Nobody remaining knows the account exists, which is exactly the secret sprawl and ownership decay the ratios above predict at scale.

An attacker running automated repository scanning finds the key and authenticates. Nothing challenges the login. There is no MFA prompt to fail, no device check, and no impossible-travel heuristic worth firing, because etl-prod already runs around the clock from cloud provider IP ranges. To every control watching the front door, this session is indistinguishable from the ten thousand legitimate ones before it.

Inside, the attacker enumerates what the account can reach and finds the permissions it was granted at creation, which were never narrowed. They also mint a second key on the same account, so that when the leaked one is eventually rotated, their access survives. Then they export warehouse tables to an external bucket over several nights, throttled to match the account's normal ETL rhythm. Rotation, the fix most teams reach for first, would have removed the original credential while leaving both the identity's permissions and the attacker's persistence fully intact.

Every step in this chain is a valid authentication by a valid identity. The only detectable signal is behavioral: an account whose established purpose is loading data into the warehouse has started pulling data out of it. That is a runtime observation, and no amount of credential hygiene produces it.

How do you stand up an NHI security program?

Most programs fail by starting in the middle, buying a vault or a scanner before anyone can say how many NHIs exist or what they are for. The sequence below front-loads the two questions everything else depends on: what exists, and who answers for it.

The order matters. Vaulting a secret whose identity nobody owns just moves an unowned risk into nicer storage, and rotating credentials on an overprivileged account leaves the blast radius untouched. Discovery and attribution first, credential modernization second, runtime observation as the layer that catches what the first two miss.

• Discover across every issuing surface: cloud IAM, directories, SaaS admin consoles, CI/CD systems, and code. Expect the count to be a multiple of your guess; identity sprawl means no single console sees more than a fraction
• Attribute each NHI to a human owner and a one-sentence purpose. Anything unclaimed after a defined window enters a monitored decommission queue rather than living on by default
• Rank by blast radius, not by count. An account with admin over production outweighs a hundred read-only tokens, and entitlement analysis tells you which is which
• Replace static secrets with platform-issued, short-lived credentials where the platform supports it, using workload identity federation and ephemeral credentials so there is no long-lived artifact to leak
• Vault what cannot be modernized yet, with secrets management treated as a waypoint for legacy credentials, not the program's destination
• Put every NHI on a lifecycle with an expiry or review date, and move high-privilege access to just-in-time grants so standing permission becomes the exception
• Instrument runtime last but permanently: baseline each identity's normal behavior and alert on deviation from purpose, because this is the only control that works when everything upstream has already failed

How do NHIs actually authenticate?

Not all NHI authentication is equally risky, and the differences explain most of the guidance above. NHI credentials sit on a spectrum, and each step along it binds authentication more tightly to the actor rather than to an artifact anyone could hold.

At the weak end are static bearer secrets: API keys, passwords, and long-lived tokens. Whoever presents one is the identity, full stop, which is why a key in a repository is equivalent to the account itself. One step up are platform-issued short-lived tokens, where a cloud provider hands a workload a credential that expires in minutes, shrinking the window a leak is useful. Further along is federation, where a workload proves its identity to one platform using a token issued by another, removing stored secrets from the exchange entirely. At the strong end is attested identity in the style of SPIFFE, where the platform cryptographically verifies what the workload is, its image, its node, its service account, before issuing anything.

AI agents add a layer the spectrum does not capture: delegation. An agent may authenticate flawlessly as itself and still act on behalf of a user whose authority it exceeds, the classic confused deputy shape. Strong workload authentication answers who the actor is; it says nothing about whose authority the actor is exercising, which is why agent identity needs both.

Which mistakes stall NHI programs?

The recurring failures are less about missing tools than about importing assumptions from human identity or from secrets scanning. The OWASP NHI Top 10 is a useful checklist baseline, but the pattern behind most of its entries is the same category error this page opened with: managing credentials as if they were the identities.

• Running it as a secrets project: scanning repos and rotating keys addresses the artifact while the actor keeps every permission it had, so the same finding reopens after every rotation
• Rotating without narrowing: rotation restores the status quo, including the overprivilege; each rotation is the natural moment to also cut scope, and most teams skip it
• Treating the vault as the finish line: a token vault protects credentials at rest and says nothing about what sessions do with them once issued
• Applying the PAM playbook wholesale: checkout workflows and session recording were built for human admins, and the PAM versus IAM assumptions behind them break at machine speed and machine volume
• Counting only cloud IAM: SaaS-resident bots, OAuth grants, and automation tokens live outside the cloud console, and programs scoped to one issuing surface miss the majority of the population
• Measuring inventory size instead of blast radius: a shrinking NHI count feels like progress while the ten identities that could empty the warehouse remain untouched
• Deferring the agent population: AI agents are the fastest-growing NHI class and the least deterministic, so a program designed only for cron jobs and pipelines is obsolete on arrival

Frequently asked questions

Related terms