Skip to main content
NEW · Blast Radius: a field playbook for leaked API keys on AWS, GCP and Azure
Identity & access

What is a Non-Human Identity (NHI)?

Also known as: NHI · Non Human Identity · Non-Human Identities · Machine Identity · 비인간 신원 · 비인간 아이덴티티 · 기계 신원 · 머신 아이덴티티 · NHI 보안

A digital identity used by software or a workload to authenticate without a person signing in for each request. Examples include service accounts and workload identities; API keys and tokens are credentials these identities may use. Check who owns the identity, which resources it can access, and how its credentials expire or are revoked.

Examples of non-human identities

A scheduled reporting job can use a Google Cloud service account to read a storage bucket. The account is the identity; its IAM roles determine which operations are permitted.

An application running on AWS can assume an IAM role and receive temporary credentials. The role does not need a permanent access key. Microsoft Entra service principals and managed identities are other examples of identities used by applications and services.

Is an API key a non-human identity?

An API key or token is a credential. What it represents depends on the issuing service: it may grant access for a workload, an application or a person. Check that relationship before classifying it as an NHI credential.

One identity may use several credentials over time. Replacing a leaked key does not necessarily change the identity’s permissions, and finding several copies of a key does not mean several identities exist.

Why is non-human identity security important?

Automated services need access even when no person is present to approve each request. If a usable credential is exposed, someone else may be able to exercise its permissions. A workload can also retain access after its purpose or responsible team changes.

An investigation needs the identity, current access and responsible owner as well as the exposed value. A secret scan can locate a credential, but the finding alone does not establish its permissions, ownership or misuse.

What to check for each NHI

Record the workload’s purpose and owner, the issuer and identity identifier, allowed actions and resources, credential locations and expiry, and available usage logs. Review whether the workload can use short-lived credentials or federation instead of a stored long-lived key.

When access is no longer needed, remove it at the issuer and check the dependent workload. For a live exposed key, coordinate replacement and revocation with its owner, then review issuer logs for unexpected activity.

More terms in Identity & access

Browse the full glossary

30 terms organized by category.