Non-Human Identity (NHI)

What is Non-Human Identity (NHI)?

A non-human identity (NHI) is any credential or identity used by an application, service, script, pipeline, or automated process to authenticate and access systems — rather than a human user typing a password. Service accounts, API keys, OAuth tokens, machine certificates, bot credentials, cloud workload identities, and CI/CD pipeline tokens are all non-human identities.

In most enterprise environments, NHIs outnumber human identities by a ratio of ten to one or more. In cloud-native organisations running microservices architectures, the ratio is often far higher. And they're almost universally under-governed compared to the human identities that get reviewed in quarterly access certification cycles.

That's the gap. NHIs access the same sensitive data, the same production databases, the same cloud storage, the same regulated systems that human identities access. But they rarely appear in access reviews, rarely have their credentials rotated on schedule, and rarely have behavioural baselines that would make anomalous activity detectable.

What counts as a non-human identity

The NHI category is broader than most access governance programmes account for.

Service accounts. Named accounts in Active Directory, Entra ID, or cloud IAM that represent applications or services rather than people. A database backup service running under svc-backup@domain.com. An ETL pipeline authenticating as svc-dataplatform. A monitoring agent using svc-monitoring. These look like user accounts, live in the same directory, and accumulate permissions the same way human accounts do.

API keys and tokens. Static credentials issued to applications or developers to authenticate API calls. An application that calls a SaaS platform's API uses an API key. That key has permissions scoped to the calling application's needs — or it should have, though it frequently has broader access than necessary. API keys don't expire by default on most platforms unless a rotation policy is enforced.

OAuth tokens and service credentials. Short-lived or long-lived tokens issued to applications following OAuth flows. An integration that reads from Google Workspace uses an OAuth token scoped to that application's permissions. Long-lived refresh tokens can persist access for extended periods without re-authentication.

Machine certificates. TLS client certificates used for mutual authentication between services. Infrastructure components proving their identity to other components as part of service mesh communication.

Cloud workload identities. IAM roles assigned to cloud compute resources: an EC2 instance with an IAM role that grants S3 read access, a Lambda function with permissions to write to DynamoDB, a GKE pod with a Workload Identity bound to a GCP service account. The workload authenticates using the cloud platform's native credential mechanism without any human-managed secret.

CI/CD pipeline identities. Credentials used by deployment automation: GitHub Actions secrets, Jenkins service accounts, Terraform state backend credentials. These identities often have broad permissions because deployment automation typically needs to create and modify infrastructure.

Why NHIs create security risk

Four patterns account for most NHI-related security incidents.

Over-privileged access. Service accounts and API integrations are typically provisioned with the access their developers thought they might need rather than the minimum required for their actual function. That scoping is rarely revisited. An integration provisioned with broad database read access to query one specific table retains that broad access indefinitely, even if the original justification was temporary or the integration's purpose narrowed over time.

A service account with SELECT * on the entire customer database, when its only legitimate function is to query the orders table, has excess access that an attacker or compromised process can exploit. The account doesn't need a password crack. It's already authenticated and already has access.

Stale credentials never rotated or revoked. Human accounts get deprovisioned when employees leave. NHI credentials are rarely managed with the same lifecycle rigour. An API key issued to a contractor integration three years ago, for an integration that was decommissioned two years ago, often still exists, still works, and still has the permissions it was originally granted. Nobody revoked it because nobody tracked when the integration was shut down or confirmed the key was rotated.

That stale credential is an unmonitored doorway. If it's compromised — leaked in a code repository, discovered by an attacker through credential stuffing, or included in a data dump — it provides access to whatever it was provisioned for, with no active monitoring of its usage.

Secret sprawl. API keys, tokens, and connection strings frequently end up embedded in source code, configuration files, CI/CD environment variables, and shell scripts rather than in dedicated secrets managers. A developer hardcodes a database connection string to get something working quickly. It gets committed to the repository. The repository gets cloned. The credential propagates.

GitHub's secret scanning and similar tools detect some of this. But secrets that were committed and then removed from history are often still active. The credential was exposed. The rotation never happened.

No behavioural baseline. The reason anomalous NHI activity often goes undetected is that nobody established what normal looks like for each NHI. Human identity monitoring benefits from years of developing what reasonable access patterns look like for different roles. NHIs typically have no baseline at all.

A service account that runs a specific ETL job nightly has an extremely predictable access pattern: same queries, same tables, same time window, same data volume. If that account suddenly runs different queries against different tables at a different time and at ten times the normal data volume, that deviation is highly anomalous. But it's only detectable as anomalous against a baseline that was established in the first place.

NHI vs service accounts

Service accounts are a subset of NHI. The distinction matters for governance scoping.

All of these are non-human identities. Access governance programmes that focus only on service accounts in the corporate directory are missing the API keys, OAuth tokens, cloud workload identities, and pipeline credentials that may have equivalent or broader access to sensitive data.

Why NHI matters for data security

The evidence pack that matters.ai generates when it attributes data access to identities explicitly distinguishes human and non-human actors. That distinction matters operationally. A service account querying a sensitive database at 2am is a different risk signal than a human user doing the same thing, because the service account has no legitimate 2am use case if it's a scheduled ETL job that only runs during business hours.

The data security implication is direct: NHIs touch sensitive data continuously, often at higher volumes than human users, and their access patterns are far more predictable — which means deviations are far more meaningful as risk signals. But only if someone is watching.