# What is a non-human identity (NHI)?

> A non-human identity is an account or credential used by software, such as a service account, CI token or API key. Why they outnumber people and go unwatched.

URL: https://crunu.com/learn/non-human-identity
Language: en
Updated: 2026-10-30

A non-human identity (NHI) is any identity that software uses to authenticate rather than a person: a cloud service account, a CI pipeline's token, an API key held by a backend, a machine's certificate, a bot account on a Git host, and increasingly an AI agent's credentials.

## Why the category exists

Identity programs were built around people: onboarding, single sign-on, second factors, offboarding. Software identities get none of that by default. They are created by whoever needed them, often with broad permissions, and they don't leave the company or change teams, so nothing prompts anyone to review them.

The OWASP [Non-Human Identities Top 10](https://owasp.github.io/www-project-non-human-identities-top-10/2025/top-10-2025) lists the failure modes that result, and the names alone are a useful checklist:

1. Improper offboarding
2. Secret leakage
3. Vulnerable third-party NHI
4. Insecure authentication
5. Overprivileged NHI
6. Insecure cloud deployment configurations
7. Long-lived secrets
8. Environment isolation
9. NHI reuse
10. Human use of NHI

The last one is worth a second look: people "misuse NHIs for manual tasks that should be performed using individual human identities", for example a developer querying production with the application's database password. That erases the difference between what the app did and what a person did.

## What good looks like

- **An owner for each one.** A team, not a person who might leave.
- **One identity per workload.** A separate identity for the test job, the deploy job and the production service, so each can be scoped and revoked alone.
- **Narrow permissions** and separate identities per environment.
- **Short-lived credentials** where the platform supports them; see [short-lived credentials](https://crunu.com/learn/ephemeral-credentials) and [workload identity federation](https://crunu.com/learn/workload-identity-federation).
- **Inventory and review.** Last-used dates, and removal of what nobody uses.

## Common mistakes

- **A personal token running automation.** It ties a workload to a person's account, which breaks at offboarding or, worse, doesn't.
- **One credential for many services.** A leak can't be traced and can't be fixed in one place.
- **No expiry and no review.** The credential becomes [orphaned](https://crunu.com/learn/orphaned-credentials).

## Non-human identities in Crunu

Crunu has two kinds of non-human identity, and its code calls them both "identities": **machines**, servers running the `crunu` agent, and **service tokens**, used by CI. People are members; software is one of these two.

- A **machine** is enrolled with a one-time code, gets its own keys, and receives only the environments granted to it. It holds a lease and loses access when revoked.
- A **service token** is created in an admin's browser and shown once; the server knows only its public keys. It gets only its environments, can have a lease, a usage limit and network restrictions, and can be bound to a CI job with OIDC.
- The **Operator** role lets a person enroll machines and request access for them without being able to read any values.

Neither kind can read an environment it wasn't granted, because it never receives that environment's key. The CI side is covered in [CI/CD secrets with OIDC](https://crunu.com/guides/ci-cd-secrets-with-oidc).

## Sources

- [OWASP Non-Human Identities Top 10 (2025)](https://owasp.github.io/www-project-non-human-identities-top-10/2025/top-10-2025), checked October 30, 2026.