What is a non-human identity?

The one-sentence definition

A non-human identity is any digital identity that authenticates and is authorised on behalf of a software entity, an application, workload, automated process, AI agent, or integration, rather than on behalf of a human user.

That is the useful definition. Every other characteristic flows from this one distinction. Humans open a browser and enter a password; NHIs wake up as a process and present a credential (a key, a token, a certificate) that identifies them to another system. Humans have a face, a manager, a laptop, and a joiner-mover-leaver lifecycle managed through HR. NHIs have none of those things. And that is precisely the problem: the entire apparatus of enterprise identity governance (single sign-on, multi-factor authentication, access reviews, joiner-mover-leaver workflows, onboarding, privilege elevation, quarterly recertification) was designed for the human case. Extending it to the non-human case requires either major effort or a dedicated category of tooling.

The NHI taxonomy, nine categories

There is no single canonical taxonomy of NHI types. The OWASP working group, the Cloud Security Alliance, and individual vendors each carve the space slightly differently. The nine-category structure below is pragmatic and covers, in our experience, more than 95% of the identities a working practitioner will encounter.

1. Service accounts

The oldest and most numerous NHI category. A service account is a user-like account created in an identity directory, Active Directory, LDAP, a Linux system, a database, not for a human but for an application or automated process. Service accounts authenticate with a password (or, better, a certificate or key) and are granted specific permissions. They are the identity behind the nightly batch job, the internal CRM's connection to the database, the monitoring agent that scrapes logs.

2. API keys and personal access tokens (PATs)

Long-lived credential strings issued to authenticate API calls. Cloud providers, SaaS platforms, and developer tools all issue them. A GitHub Personal Access Token. A Stripe secret key. An AWS access key ID plus secret access key. They are designed to be easy to use, which has historically meant easy to leak, the category implicated in the Codecov, and dozens of other breaches.

3. OAuth and OpenID Connect tokens

Short-lived (typically) bearer tokens representing a delegated authorisation. When you "connect" one SaaS app to another, Slack to Google Drive, Salesforce to Zoom, a CRM plug-in to your email, the mechanism underneath is typically OAuth 2.0. The resulting refresh token, stored by the receiving app, is a non-human identity that authorises continued access. The Salesloft/Drift breach of August 2025 was an OAuth-token-theft incident at a previously under-attacked scale.

4. Cloud IAM identities (roles, service principals, managed identities)

The cloud-provider-native form of NHI. AWS IAM roles. Azure service principals and managed identities. Google Cloud service accounts. These are the identities that a workload assumes when running in the respective cloud, and they are typically granted permissions through policy documents, the source of most cloud over-privilege problems.

5. Kubernetes service accounts

A Kubernetes-native NHI type, distinct from the underlying cloud identity. Every pod runs under a service account, and the service account's token is mounted into the pod filesystem. Via OIDC-based workload identity federation, Kubernetes service accounts can also be mapped to cloud IAM identities, which is one of the primary workload-identity bridge patterns in production.

6. Certificates (X.509) and cryptographic keys

Mutual TLS certificates, code-signing certificates, SSH keys, JWT signing keys. This is the category most tightly associated with "machine identity" in the Venafi/Gartner sense. A certificate asserts the identity of one endpoint to another and is typically issued by a PKI hierarchy. Expiry and rotation are the lifecycle events that matter most, expired certificates are the source of a substantial fraction of outages.

7. SSH keys

A specific, stubborn NHI category that predates almost everything else. SSH keypairs grant access to servers. In most enterprises, SSH keys are long-lived, manually managed, rarely inventoried, and rarely rotated. Ephemeral SSH certificates (via something like Teleport, Smallstep, or HashiCorp Boundary) are the modern alternative.

8. Workload identities

The architectural pattern in which an identity is bound to a workload's cryptographic identity (rather than a shared secret) and attested by the infrastructure. This is the world of SPIFFE and SPIRE, AWS IAM Roles Anywhere, GCP Workload Identity Federation, and the IETF WIMSE working group's standardisation effort. Workload identity is the category that makes static API keys and service-account passwords obsolete, once deployed, everywhere.

9. AI agents and MCP servers

The newest NHI category, and arguably the fastest-growing. An AI agent, a language model acting with tools, memory, and goals, needs to authenticate itself to the systems it touches, needs its own permissions, and needs its own lifecycle and auditability. The Model Context Protocol (MCP) introduced another sub-layer: MCP servers are NHIs that expose capabilities to agents, and their own authentication boundaries matter. Covered in depth in the AI agent identity hub.

Concrete examples from a typical enterprise

To make the abstract taxonomy concrete, here is a non-exhaustive list of NHIs from a reasonably typical mid-size enterprise. Every one of these is a non-human identity that, if compromised, can read data, write data, or execute actions on behalf of the organisation:

• The GitHub Personal Access Token in the CI/CD pipeline that deploys the production app.
• The AWS IAM role attached to the Lambda function that processes webhooks from the payment provider.
• The OAuth refresh token stored by the sales-engagement tool for access to the customer CRM.
• The service account in Active Directory that runs the nightly finance-data ETL job.
• The Kubernetes service account assigned to the monitoring agent running in every cluster.
• The SSH keypair on the developer's laptop that still has root on a decommissioned bastion host.
• The mutual-TLS certificate that authenticates the internal microservice mesh.
• The API key baked into the mobile app (it is on every customer's phone).
• The Azure service principal used by the Terraform pipeline to manage the cloud estate.
• The OpenAI API key stored by the internal LLM-powered chatbot agent.
• The MCP server running in the developer's IDE that accesses the ticket system.
• The Slack bot user that posts deploy notifications to engineering channels.

In a mid-size enterprise there are thousands of these. In a cloud-native enterprise there are tens of thousands. Many are undocumented. Many have lived longer than the employees who created them.

Why "non-human" matters as a distinction

The distinction is not cosmetic. Non-human identities differ from human identities on every axis that identity governance tooling cares about:

The cost of ignoring the distinction is cumulative. Every IAM control that assumes a human on the other end, MFA, behavioural baselining, manager-driven access reviews, silently becomes ineffective when the identity is non-human. That is how a mature human-identity programme can still produce the kind of breaches enumerated in our breach catalog.

The 45× problem

The single most-cited statistic in NHI discourse is the ratio of non-human to human identities in the average enterprise. Estimates vary by methodology but cluster in a consistent range:

• The Cloud Security Alliance's 2024 State of Non-Human Identity Security survey reported ratios of roughly 20:1 to 50:1 depending on industry and cloud maturity.
• Astrix Security's 2023 analysis across ~200 enterprise deployments reported an average of 45 NHIs per human employee.
• Vendor product data from Oasis Security, Entro, and others produces similar order-of-magnitude ratios, typically 20×-to-100× once SaaS-to-SaaS connections and Kubernetes service accounts are fully counted.

The direction is what matters more than the precise multiplier. As organisations adopt more SaaS tools, more cloud services, more microservices, and more AI agents, the ratio moves up, not down. A five-year-old enterprise on an early-2020s architecture might have been at 10:1. A cloud-native, SaaS-heavy, AI-enabled enterprise in 2026 is typically past 50:1 and often past 100:1.

How non-human identities get attacked

Three attack patterns dominate real-world NHI-driven breaches. If you are scanning for risk, these are the patterns to hunt for first.

Pattern 1, The long-lived credential leak

A static credential (API key, access token, SSH key, service-account password) makes it into a place it should not be, a public GitHub repo, a container image pushed to a public registry, a developer's personal cloud storage, a chat message in a compromised Slack. An attacker finds it, uses it, and, because the credential has no MFA, no short expiry, and no anomaly detection, uses it for weeks or months before discovery. The 2021 Codecov Bash Uploader breach, the 2022 Uber MFA-fatigue + internal-script incident, and the 2023 Codecov breach all fit this pattern with minor variations.

Pattern 2, The orphaned identity

An NHI is created for a purpose, an integration, a script, a short-term project, and then never decommissioned. The purpose goes away; the identity does not. Five years later, the credential is still valid, still holds its original permissions, and has no owner to whom anomalies can be reported. This is the OWASP NHI Top 10 top-ranked risk: NHI1, Improper offboarding. The 2023 Microsoft Storm-0558 breach, in which a 2016-era Microsoft Services Account signing key was used in 2023 to forge tokens against 60,000 US State Department emails, is an orphaned-identity case study at scale.

Pattern 3, Over-privilege and lateral movement

An NHI is granted broad permissions for convenience and never right-sized. When the NHI is compromised, even through a minor path, like a logged credential, the attacker inherits those broad permissions and can pivot across the environment. The 2024 Snowflake breach affecting 165 customers (UNC5537) is a mixed-pattern incident where static customer credentials (single-factor) granted privileges that allowed mass data exfiltration from multiple companies once individual NHIs were compromised via infostealer logs. Over-privilege is OWASP NHI5 in the Top 10 taxonomy.

NHI vs. machine identity, what to call all of this

The two terms in common use, non-human identity and machine identity, refer to overlapping but not identical categories. The short version:

• Machine identity historically centres on the machine as the identity-bearing unit, especially via certificates and keys. Venafi (now CyberArk), Gartner's "Machine Identity Management" category, and most PKI-anchored vendors use this framing. It captures categories 6, 7, and parts of 4 and 8 in our taxonomy.
• Non-human identity is the broader umbrella that includes service accounts, OAuth tokens, SaaS-to-SaaS, and AI agents, identity constructs that are not naturally machine-bound. NHIMG, OWASP, Astrix, Oasis, Entro, and most newer vendors use this framing.

We use NHI as the umbrella because it is the wider and more useful term, and treat "machine identity" as a specific subset, the certificate-and-key sub-domain of NHI. Our full treatment, including the history and the industry debate, is in NHI vs. machine identity.

What NHI governance looks like in practice

A mature NHI programme has recognisable components. They mirror, at high level, the structure of a human IAM programme, but with different primitives and different tooling.

• Inventory. A centralised, automatically discovered record of every NHI across directories, cloud accounts, SaaS tools, CI/CD systems, and Kubernetes clusters. This is where most programmes start and where most programmes fail, without inventory, nothing else is possible.
• Ownership. Every NHI has a named, current human owner (a person or a team). When that ownership breaks (the owner leaves, the team reorganises), the NHI is flagged for re-ownership or decommissioning.
• Credential hygiene. Secrets are stored in a central secrets manager, not in code. Credentials are short-lived where possible. Rotation is scheduled, not ad hoc.
• Least privilege. NHIs are scoped to the minimum permissions they need, with regular right-sizing.
• Lifecycle management. Offboarding is triggered by identifiable events (employee departure, application decommissioning, integration removal), not left to be remembered.
• Behavioural monitoring. NHI behaviour is baselined and anomalies are alerted. The tooling category for this is sometimes called ITDR (identity threat detection and response) or NHIDR.
• Third-party integration governance. OAuth applications and SaaS-to-SaaS connections are reviewed on installation, re-reviewed on change, and revoked on deprecation.
• Workload identity adoption. Where possible, static credentials are replaced with workload-bound identities (SPIFFE SVIDs, workload identity federation) that cannot be copied or re-used.

The NHI management pillar page expands on each of these. The 5-stage maturity assessment is how we measure progress against them.

Frameworks to anchor your thinking to

The field is crowded with vendor taxonomies. A small number of vendor-neutral frameworks are worth anchoring to:

• OWASP NHI Top 10 (2025), the canonical risk taxonomy: NHI1 Improper offboarding, NHI2 Secret leakage, NHI3 Vulnerable third-party NHI, NHI4 Insecure authentication, NHI5 Overprivileged NHI, NHI6 Insecure cloud deployment configurations, NHI7 Long-lived secrets, NHI8 Environment isolation, NHI9 NHI reuse, NHI10 Human use of NHIs.
• SPIFFE and SPIRE, the CNCF-graduated architecture for workload identity, underneath a growing portion of the industry's zero-trust workload story.
• IETF WIMSE, the standards-track working group at the IETF formalising workload identity at the protocol level.
• CSA State of Non-Human Identity Security, the Cloud Security Alliance's annual survey and program guidance.

Frequently asked questions

Is a non-human identity the same as a service account?

No. A service account is the oldest and most common type of NHI, but the NHI umbrella also covers API keys, OAuth tokens, cloud IAM roles, Kubernetes service accounts, certificates, SSH keys, workload identities, and AI agents. "Service account governance" is a subset of non-human identity governance.

Why can't I just use my existing IAM programme for NHIs?

Two reasons. First, the primitives differ, NHIs authenticate with keys and tokens rather than MFA-assisted passwords, and most human IAM tooling assumes the latter. Second, the scale differs, managing 100,000 identities per year through the processes designed for 1,000 human identities does not work. Most organisations end up extending human IAM where it extends cleanly (e.g. access-review concepts), and adopting specialised NHI tooling for the primitives and scale specific to NHI.

Are AI agents really a separate NHI category?

Operationally, yes. An AI agent with tool-use capability, memory, and goal-directed behaviour has identity-governance problems that are only partially shared with classical NHI patterns. Delegation chains ("the agent acts on behalf of a specific user"), prompt-injection-driven authority escalation, and the sheer unpredictability of what an LLM-driven agent will do with a credential make the governance problem distinct. Most major vendors (Microsoft Entra Agent ID, SailPoint Agent Identity Security, specialised startups like Keet) have announced dedicated product work here. See the AI agent identity hub.

Where do I start if I've never thought about this formally?

Discovery. Pick one of the three categories that probably has the most leakage in your environment, it is usually either long-lived API keys in CI/CD, service accounts in Active Directory, or OAuth-connected SaaS apps, and get an inventory. The inventory will tell you what you already have, which is almost always considerably more than leaders assume. From there, prioritise rotation and ownership for the most-privileged subset. Our maturity assessment produces a prioritised three-step plan for your specific stage.