What Are the Types of Non-Human Identities?

Quick answer
A non-human identity is any identity that authenticates a workload, service, bot, or agent rather than a person.
The main types are service accounts, API keys, OAuth clients, TLS and SSH certificates, cloud IAM roles, workload identities, and agent or bot tokens.
They differ in whether the credential is a bearer secret, a signed certificate, or a short-lived token issued by a platform.
The type determines the control: static keys need rotation and scoping, while platform-issued identities can be short-lived and attested.
Most breaches involving NHI come from long-lived static credentials with broad permissions, not from exotic identity types.

What counts as a non-human identity?

A non-human identity is the identity a program presents when it calls another system. It might be a database user, a cloud role, a GitHub App installation, a service account token, or an API key attached to an outbound request. The common property is that no person types a password at the moment of use, so the credential must be stored, issued, or derived somewhere.

That storage is the risk. A human identity can be protected by a second factor and a login prompt; a non-human identity is only as protected as the place its credential lives and the permissions attached to it. Classifying the identity by how its credential is obtained is therefore more useful than classifying it by the vendor that issued it.

What are the main types?

Static secrets include API keys, passwords, and connection strings: long-lived bearer strings that grant whatever the server associates with them. Service accounts are identities inside an application or platform, often authenticated by a password or key but with permissions registered in that system. OAuth clients authenticate an application and receive tokens, using either a client secret or a stronger assertion.

Certificate-based identities use mutual TLS or signed tokens tied to a key pair. Workload identities are issued by a platform after attesting the workload, and are typically short-lived. Agent and bot tokens are scoped credentials for chat platforms, automation, and AI agents, often with broad workspace permissions because the scope options are coarse.

| Type               | Credential form        | Lifetime      | Primary control                    |
|--------------------|------------------------|---------------|-------------------------------------|
| API key            | Bearer string          | Long          | Scope, rotate, monitor last used    |
| Service account    | Password or key        | Long          | Least privilege, disable unused     |
| OAuth client       | Secret or assertion    | Medium        | Short tokens, audience restriction  |
| mTLS certificate   | Key pair + cert        | Medium        | Short validity, revocation          |
| Workload identity  | Platform-issued token  | Minutes       | Attestation, audience, trust policy |
| Bot/agent token    | Bearer string          | Medium to long| Workspace scope, approval flow      |

Which types are riskiest?

Long-lived static credentials with broad scope are the riskiest, because a single leak is directly usable and often does not expire. An API key with admin rights on a production account is worse than a short-lived certificate with a narrow audience, even though both are non-human identities.

The risk is compounded by invisibility. A service account created years ago and used by an undocumented cron job is still an identity, still has permissions, and rarely appears in an inventory. The type that cannot be found is more dangerous than the type that is hard to rotate.

How does identity type change the control you apply?

For static secrets, the controls are storage in a secrets manager, least-privilege scoping, rotation with a defined owner, and detection of use from unexpected locations. For platform-issued workload identities, the controls move to trust policy: which workloads are allowed to assume which role, and what conditions the platform checks before issuing a token.

For certificates, validity period and revocation matter more than storage. For agent tokens, the workspace scope is the main lever, plus an approval step for actions with external side effects. Treating every type as a generic secret leads to rotation schedules that do not fit and permissions nobody reviews.

Where this bites vibecoders
AI-generated integrations default to one pattern: an API key in an environment variable, with the key created through a dashboard and given whatever scope the UI offered. The code works, so the identity is never revisited. A short review of which type each integration uses, and whether a narrower platform identity exists, is the cheapest improvement available.

Where AI coding assistants get this wrong

Creating a new API key per integration with full-account scope because it is the fastest path.
Treating OAuth client secrets as equivalent to API keys and never shortening token lifetime.
Letting a bot or agent token inherit a personal admin account’s permissions.
Ignoring service accounts created by an AI coding assistant during setup.
Assuming a certificate is safer without checking its validity period or revocation path.
Storing every credential type in the same place with the same access.

Checklist

List every integration and the identity type it uses.
Mark which credentials are static and which are platform-issued.
Scope each identity to the specific resource it needs.
Assign a human owner to every identity.
Set an expiry or rotation interval for static secrets.
Replace static cloud keys with workload identities where possible.

FAQ

Is a service account a non-human identity?

Yes. A service account is an identity registered in an application or platform for non-human use. It may authenticate with a password, a key, or a short-lived token, but the identity itself is non-human because no person completes an interactive login. Service accounts are one of the most common NHI types.

Are OAuth tokens non-human identities?

The OAuth client is the non-human identity; the access token is the credential it receives. That distinction matters because a client credential is a long-lived secret while access tokens can be short-lived. Securing the client secret and restricting the token audience is what makes the identity safe.

What is the difference between a machine identity and an NHI?

They overlap heavily. Machine identity usually refers to certificates and keys that establish a machine’s identity, especially in TLS; non-human identity is broader and includes API keys, service accounts, bots, and agent tokens. Most teams use the terms interchangeably in practice.

How many non-human identities does a typical app have?

More than the team can name. Each cloud role, database user, CI token, monitoring agent, and third-party integration is one. The count grows with every service added and rarely shrinks, which is why inventory and ownership matter more than the initial classification.