What is non-human identity?
Non-human identity (NHI) refers to credentials and access patterns used by services, scripts, and agents — workload identities, machine identities, and automation accounts — distinct from human user accounts.
NHI is also called machine identity, workload identity, or service identity. The Cloud Security Alliance, Gartner, and the SPIFFE project (CNCF graduated) all use overlapping terminology. The umbrella term has gained adoption in 2023–2025 as enterprises realized that non-human credentials outnumber human ones by a large factor and are governed less rigorously.
The NHI inventory most teams discover
When a team first surveys its non-human credentials, the inventory typically looks like this. Numbers vary, but the shape is consistent across Series-A to Fortune 500.
| Category | Where it lives | Typical failure mode |
|---|---|---|
| IdP service accounts | Okta / Google / Entra | No owner, no rotation policy |
| Cloud IAM roles | AWS / GCP / Azure | Overscoped (*:*) from prototype days |
| Kubernetes ServiceAccounts | Cluster control plane | Long-lived tokens mounted into pods |
| SSH host keys | /etc/ssh on every host | Pinned by fingerprint, never rotated |
| CI / automation tokens | GitHub Actions, Jenkins | Personal access tokens with admin scope |
| Integration API keys | Vendor dashboards | Created once, used forever, no audit |
Standards worth knowing
- SPIFFE / SPIRE — workload-identity standard from the CNCF. Defines
spiffe://URIs, X.509 SVIDs, and JWT SVIDs. Provides an attestation framework so workloads can prove their identity to a local SPIRE agent. - OAuth 2.0 client credentials grant (RFC 6749 §4.4) — the canonical pattern for machine-to- machine API access. Pairs with JWT bearer tokens (RFC 7523) for key-based client authentication.
- OpenSSH host certificates — covered in the SSH CA FAQ; the SSH-native NHI mechanism.
- NIST SP 800-63 — identity assurance guidance applicable to non-human as well as human identities.
Where Linux Identity fits
Our scope is Linux fleet access — both human and non-human. Hosts enroll once and receive a host certificate from the same CA that signs user certs. Automation (deploy bots, agents, observability) gets service certificates with workload-named principals and short TTLs. Every cert issuance is logged to the same append-only audit log as human access, so the NHI graph is observable without a separate inventory system.
More questions
- What kinds of credential count as non-human identity?
- Five common categories. (1) Service accounts in an IdP — accounts not tied to a person, used by an application to call APIs. (2) Cloud IAM roles assumed by workloads (AWS IAM roles, GCP service accounts, Azure managed identities). (3) Kubernetes ServiceAccounts and their projected tokens. (4) Machine certificates — X.509 SVIDs (SPIFFE), TLS client certificates, SSH host certificates. (5) API keys and tokens issued to CI systems, integrations, and webhooks. The common feature: no human is in the authentication path at runtime.
- Why is non-human identity hard to manage?
- Three reasons. (1) Proliferation: a typical mid-sized cloud estate has 10–50× more non-human identities than human ones, and they multiply with every new service. (2) No offboarding event: humans leave, which triggers cleanup. A service that stops being used quietly retains its credentials forever. (3) Ambiguous ownership: a service account created by an engineer who left three years ago is hard to retire safely. The result is long-tailed credential rot — secrets in code, unused IAM roles, dead service accounts holding production access.
- What standards apply to non-human identity?
- SPIFFE (Secure Production Identity Framework For Everyone) defines a workload-identity standard centered on the SPIFFE Verifiable Identity Document — an X.509 certificate or JWT carrying a URI-shaped identity like
spiffe://prod/billing. SPIRE is the reference implementation. NIST SP 800-63 covers identity assurance broadly. For SSH specifically, host certificates issued by an SSH CA give services and hosts the same identity-bound short-lived credential model as users. Cloud providers each ship their own non-human identity primitive (IAM roles, GCP service accounts, Azure managed identities) which are non-portable but well-integrated. - How does NHI relate to SSH?
- Two intersections. First, SSH host keys are non-human credentials: every server needs an identity to prove to its clients. OpenSSH host certificates (signed by a host CA) replace pinned host keys with a verifiable identity tied to a hostname pattern. Second, automation that uses SSH — CI runners, deployment scripts, observability agents — needs its own non-human identity. The clean pattern is short-lived SSH certificates issued from the same CA, with principals naming the workload, not a person.
- How is non-human identity different from AI agent identity?
- Traditional NHI assumes the workload is deterministic: a billing service does billing things, with a fixed scope. AI agents are non-deterministic: an LLM-based assistant might generate a plan that calls dozens of tools in an order the operator didn’t anticipate. That breaks the static least-privilege model. AI agent identity is an emerging sub-category of NHI that adds runtime policy evaluation, capability tokens minted per action, and reasoning-chain audit — concerns that don’t apply to a CI runner.