Zpedia 

/ What Is a Non-Human Identity (NHI)?

What Is a Non-Human Identity (NHI)?

A non-human identity (NHI) is a digital identity or credential that software workloads, applications, APIs, devices, and AI agents use to authenticate and execute tasks. Unlike human identities, NHIs operate autonomously in machine-to-machine interactions, with no person approving each request. Every NHI grants access to data and systems, which makes it a target for attackers.

How Are Non-Human Identities Different from Human Identities?

Human identities are tied to specific individuals who sign in and work at human pace. Non-human identities belong to machines and run automatically at machine speed. They not only outnumber human logins by a wide margin, but they are also much harder to monitor and govern.

An NHI is the authenticated digital representation of a non-human entity. Cloud workloads, databases, SaaS applications, and IoT devices all have them. Instead of passwords and multifactor authentication (MFA) prompts, they authenticate with API keys, service accounts, SSH keys, certificates, OAuth tokens, and service account credentials.

Key Differences Between Human and Non-Human Identities

People create NHIs at the start. After that, the identities run automated background processes without manual intervention. Some of the key differences between NHIs and human identities include:

Attribute

Human Identities

Non-Human Identities

Security Perimeter

Usernames, directories, and multifactor authentication (MFA)

No person to answer an MFA prompt, so static secrets carry the trust

Operational Speed

Interactive activity at human pace

Thousands of micro-transactions daily at machine speed, so manual monitoring falls behind immediately

Scale

Typically one account per person

A Cloud Security Alliance survey found NHIs often outnumber human identities by over 90 to 1 in many organizations, with some reports showing higher

“The other major attack surface that’s grown faster than security teams can manually track is identity, specifically, non-human identities. Service accounts, AI copilots, and agentic workloads now outnumber human users in many enterprise environments. Their permissions sprawl across cloud, SaaS, and on-prem systems in ways that no human team can reason over at speed.”
 
– Dhawal Sharma, Executive Vice President, AI Security and Strategic Initiatives, Zscaler

How Does Non-Human Identity Management Work?

Non-human identity management (NHIM) governs machine identities across their full life cycle. It starts with automated discovery of every machine account. It then replaces static secrets with short-lived access and narrows permissions to each task. Continuous monitoring tracks behavior. Unused identities retire automatically.

Secrets Management vs. NHI Management

Secrets management protects credentials through secure storage and rotation. NHI management governs the identities behind those credentials. It discovers machine accounts, assigns owners, limits privileges, and retires unused access. Secrets management is one component of the broader discipline of NHI management.

Dimension

Secrets Management

NHI Management

Primary Focus

Secure storage and automated rotation of credentials

Governance of the identities behind those credentials

Scope

Secrets registered in the vault, infrastructure-as-code templates, or emergency procedures

Every machine account, including those created outside standard workflows

Ownership

Ownership questions remain open

A designated human owner for each identity

Usage and Expiration

Usage and expiration questions remain open

Continuous monitoring of behavior and retirement of unused access

Privilege Control

Secures the secret itself

Limits privileges to what each task requires

Life Cycle Coverage

Storage and rotation

Discovery, provisioning, monitoring, rotation, and decommissioning

Relationship

One component of NHI management

The broader discipline

Traditional Credential Management vs. Zero Trust NHI Standards

Identity Attribute

Traditional Management Approach

NHIM Zero Trust Standard

Credential Lifespan

Static, long-lived keys and secrets

Ephemeral, short-lived tokens and secretless federation

Permissions Scope

Broad, static administrative privileges set at creation

Dynamic, just-in-time, and task-specific access

Lifecycle Governance

Manual onboarding with no assigned owner

Automated discovery, continuous tracking, and decommissioning

Audit Visibility

Basic connection logging

Real-time behavioral mapping and active access graphs

Continuous Automated Discovery and Cataloging

Machine identities appear faster than teams can record them. Automated scanning tools find active and legacy API keys, service accounts, and cloud workloads across cloud platforms and pipelines. Scans must extend beyond public code, since GitGuardian’s 2026 State of Secrets Sprawl report found that internal repositories are six times more likely to contain hardcoded secrets than public ones.

A unified repository of non-human accounts is the foundation for compliance and risk governance. Each record lists an owner, purpose, privilege level, and last-used date. Auditors then verify controls against one source, and security teams rank the riskiest accounts first.

Federated, Secretless Workload Identities

Secretless identity replaces hardcoded keys with federation. In OpenID Connect (OIDC) federation, a CI/CD job presents a signed token and the cloud provider exchanges it for temporary credentials. Google Cloud notes that no secrets remain to rotate or manage beyond the initial configuration, and the resulting credentials expire after one hour by default.

SPIFFE and SPIRE apply the same idea inside clusters. SPIRE verifies a workload through attestation before it issues an identity, so no long-lived static credential needs to be co-deployed with the workload. Attestation checks facts such as a Kubernetes namespace or container image. This removes the need for a bootstrap secret, which solves the “secret zero” problem of delivering the very first credential safely.

Context-Aware Agentic Access Management

Agentic access management (AAM) secures autonomous AI agents. Each agent receives its own identity and just-in-time, short-lived credentials scoped to each specific task. The Coalition for Secure AI recommends zero standing privilege for agent credentials.

Agents also need continuous runtime authorization. A multistep workflow can drift from its original goal, so a permission that was safe at step one may be risky at step five. Intent-based controls evaluate who is acting, what they attempt, and why before each action commits.

Real-World NHI Breaches and What They Reveal

There’s often a common thread behind today’s NHI breaches: attackers find a valid secret and use it, and they do so without triggering an alert. A stolen API key usually works against the system that issued it, and attackers replay it there.

An AI agent, by contrast, holds broad permissions across tools and data stores, and it chooses its own actions. A hijacked agent can read prompts, extract keys from tool outputs, and reach adjacent systems.

In both cases, the activity also looks legitimate. Stolen keys and hijacked agents behave like trusted automation, so user-centric controls rarely flag it. Defenders must watch both what an identity holds and what it does.

Notable NHI Breaches and Real-World Examples

While numerous breaches have stemmed from NHIs, three documented incidents show how attackers turn a single machine credential into broad access. Each began with a secret that was stolen or exposed.

CircleCI (2022 to 2023)

Malware on an engineer’s laptop stole a valid, two-factor-backed session. That engineer could generate production access tokens, so the attacker reached databases and exfiltrated customer environment variables, tokens, and keys. CircleCI told every customer to rotate all stored secrets.

Salesloft Drift (2025)

Attackers stole OAuth tokens that connected the Drift chat application to customer systems. From August 8 to 18, 2025, they used those tokens to query Salesforce instances and search for secrets such as AWS access keys and Snowflake tokens. The Cloud Security Alliance reports that over 700 organizations had data exposed. The trusted integration carried all the access.

Toyota T-Connect (2017 to 2022)

A subcontractor published source code to a public GitHub repository, which contained a hardcoded access key to a customer data server. The key stayed exposed for almost five years, putting the records of 296,019 customers at risk.

What Are the Top Security Challenges of Non-Human Identities?

The top security challenges of non-human identities are leaked secrets, overprivileged access, and orphaned accounts. Developers hardcode secrets in code and pipelines, administrators grant broad permissions at creation, and finished projects leave active accounts behind. These risks stay hidden until an attacker exploits them.

Secrets Vaults Can’t Stop Active Token Exploitation

Developers often hardcode API keys and secrets into application code and configuration files. Those secrets bypass the vault entirely. GitGuardian’s State of Secrets Sprawl 2026 report counted 28.65 million new hardcoded secrets in public GitHub commits during 2025. More than 64% of secrets confirmed valid in 2022 were still valid when GitGuardian retested them in January 2026. That window gives attackers ample time to discover and exploit exposed credentials.

Vaults store and rotate secrets. They have no view of a stolen token in use. A token works as a bearer key, so whoever holds it gains access, and stolen tokens bypass MFA because they represent an already-authenticated session. Stopping that activity takes inline inspection of the connection itself.

Overprivileged Workloads Increase the Blast Radius of Attacks

Teams routinely grant NHIs admin-level privileges, and regular reviews are rarely enforced. A CSA survey of 818 IT and security professionals found that only 22% of organizations review service account permissions yearly. Of the respondents, 37% named overprivileged accounts as a common cause of NHI security incidents.

One overprivileged API token can start a cascade. An attacker uses it to move laterally across connected SaaS systems. Each system holds secrets that open the next one. The Salesloft Drift campaign followed this pattern: stolen OAuth tokens opened customer Salesforce instances. Attackers then searched for AWS access keys and Snowflake tokens that led to further systems.

Zombie Accounts and Orphaned Credentials Create Hidden Entry Points

Zombie accounts are service accounts that stay active after a project ends or an employee leaves. Nobody owns them, so they don’t get reviewed. In many environments, privileges remain because no one will accept the outage risk of removing an account that no one can explain. Attackers value these accounts because their activity draws no attention, and no owner exists to notice a change.

What Is the Difference Between Secrets Management and NHI Management?

Secrets management protects credentials through secure storage and rotation. NHI management governs the identities behind those credentials. It discovers machine accounts, assigns owners, limits privileges, and retires unused access. Secrets management is one component of the broader discipline of NHI governance.

Vaults excel at storage and automated rotation. They assume credentials are registered at creation, so secrets made through cloud consoles, infrastructure as code templates, or emergency procedures create blind spots. Questions of usage, ownership, and expiration remain open.

NHI management answers those questions across the full life cycle from discovery and provisioning to monitoring, rotation, and decommissioning. Paired together, the two layers protect both the stored secret and the account that uses it.

How to Secure NHIs with Controls and Best Practices

Secure NHIs by limiting what each identity can do, how long its access lasts, and who answers for it. Enforce least privilege, issue short-lived credentials, assign a human owner to every identity, and automate retirement. Apply the same controls inside pipelines, where secrets concentrate.

Enforce the Principle of Least Privilege (POLP)

The principle of least privilege (POLP) limits each NHI to the permissions its task requires. Teams often give a new service account or workload identity a default administrative role because it works immediately, so removing that role comes first. Purpose-built roles for each workload replace shared admin access.

Permissions drift after launch, so automated entitlement reviews belong in production. NHI governance strategies should scope permissions to observed usage rather than requested usage. Reviews should also check effective access, including inherited permissions and wildcard entitlements, and not only the assigned role. Unused permissions are then removed automatically.

Implement Ephemeral Credentials and Just-in-Time Access

Short-lived certificates and tokens replace static keys. Ephemeral credentials typically expire after minutes or hours, and a certificate tied to a session ends when the session finishes.

Just-in-time (JIT) access issues credentials only when a task starts. AWS notes that temporary tokens limit the duration of any potential compromise. A stolen token that has already expired offers an attacker nothing, so the window to exploit it shrinks from years to minutes.

Establish Ownership and Life Cycle Automation

Every NHI maps to a designated human owner, such as a developer, project manager, or team lead. Governance guidance recommends enforcing this at provisioning, so the platform refuses to create an identity without an owner. Without ownership, offboarding becomes a shared assumption, and the final revocation never happens.

NHI management should connect to automation platforms. Retirement events, such as a closed project, a removed integration, or a departing employee, then trigger credential revocation immediately. Identities with no recent activity are flagged and decommissioned.

Secure NHIs in CI/CD Pipelines and Developer Environments

Pipelines hold many of an organization’s most powerful secrets. Teams can start by scanning pipeline variables for hardcoded credentials and replacing them with OIDC federation. Each pipeline stage gets its own service account, and production secrets stay reachable only from the production deployment branch.

Developer environments need clear boundaries too. OWASP lists human use of NHIs as a top risk, since developers sometimes borrow machine credentials for manual tasks. Individual identities with single sign-on cover those tasks.

Vulnerability Scenario

Business and Technical Impact

Mitigating Control

Hardcoded credentials in code

Direct system compromise through leaked repositories, followed by costly forced rotations

Automated codebase scanning, pre-commit secret detection, and transition to cloud key vaults or secretless federation

Dormant “zombie” service accounts

Undetected lateral movement after a breach, with no owner to notice misuse

Automated life cycle reviews, owner attestation, and scheduled decommissioning

Unrestricted, long-lived API tokens

Mass data exfiltration from external apps

Just-in-time token generation, short expiration, and egress filtering

Overprivileged workload roles

One stolen token reaches many connected SaaS systems

Least-privilege role design and automated entitlement reviews

Unowned NHIs

Slow incident response and failed audits

Mandatory owner assignment at provisioning, tracked in a central inventory

Pipeline secrets in CI/CD configuration files

Compromised build runners expose production access

OIDC federation, per-stage service accounts, and environment-scoped secrets

Compromised AI agents

Destruction of database records

Continuous intent analysis and runtime policy blocks

Non-Human Identity Security with Zscaler and Oasis Security

Zscaler and Oasis Security give security teams a single control plane for every human and non-human identity. Oasis Security, a pioneer of non-human identity management (NHIM), discovers, risk-scores, and manages the life cycle of credentials. The Zscaler Zero Trust Exchange™ platform adds inline enforcement. Governance and enforcement work as one system.

The Zero Trust Exchange inspects, brokers, and enforces zero trust connections across user, device, workload, and application sessions. Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) apply that enforcement to internet, SaaS, and private application traffic. Oasis supplies the identity context behind each one, including who created the identity, what it can reach, and whether anyone still owns it.

Joint customers can:

  • Discover hidden NHIs and AI agents across cloud, SaaS, and on-premises environments
  • Attribute each identity to a human owner
  • Rotate, scope, or decommission access without custom scripts
  • Block compromised connections inline, in transit

The result is one operational model for human, machine, and agentic access. Life cycle governance finds and fixes risky identities. Inline enforcement stops misuse while the connection is still in transit.

To learn more, request a demo.

FAQs

A non-human identity (NHI) is a digital identity that enables software to authenticate and execute tasks. NHIs connect machines to data and systems without human involvement. Because they outnumber human users by as much as 90 to 1 and often operate outside MFA and routine review, they are a prime target for attackers and a priority for defenders.

The most common NHIs include service accounts, API keys, OAuth tokens, SSH keys, and certificates. Cloud workloads, containers, CI/CD pipelines, and IoT devices use them to carry out proper authentication. Robotic process automation bots and AI agents also rely on NHIs to operate, as each grants a machine access to data or systems.

Human identities follow predictable events such as hiring, role changes, and departure, with HR systems triggering updates. NHIs lack the same operational rhythm and consistency. Developers create them on demand, which means ownership often goes unassigned, and there’s no defined event that signals retirement. NHI life cycle management therefore needs automated discovery, owner assignment, rotation, and decommissioning.

Traditional identity and access management (IAM) and single sign-on (SSO) tools were built for people. Service accounts and API keys authenticate with secrets, so MFA and SSO flows have no role. OAuth tokens also operate outside SSO. When a credential is compromised, no second factor stops the attacker, who inherits the identity’s access.

Secrets sprawl is the uncontrolled spread of API keys, tokens, and passwords across code, pipelines, and collaboration tools. Developers hardcode secrets into repositories, and those secrets persist in commit history long after deletion. Attackers scan public and internal repositories for valid keys and use them to reach cloud databases and services.

The OWASP Non-Human Identities Top 10 is a community-driven list of the most critical NHI risks. It gives security and development teams a common language and a ranked checklist. Categories include improper offboarding, secret leakage, vulnerable third-party NHIs, and overprivileged NHIs. Teams map their environment against the list to set priorities.

A zombie account is a service account or credential that stays active after its project ends or its owner leaves. Nobody monitors it, so misuse easily goes unnoticed. Attackers exploit orphaned credentials for unauthorized access and lateral movement, since the account’s activity blends into normal automation.

Ephemeral certificates and just-in-time tokens expire within minutes or when a session ends. A stolen credential loses value quickly, so the attacker has a short window to act. Narrow scoping limits what each token can reach. A single compromise then stays contained and cannot cascade across connected systems.

An automated central registry is a continuously updated inventory of every NHI. It records each identity’s owner, purpose, privileges, and last use. Governance teams use it to enforce policy, prove compliance, and prioritize risky accounts. A registry makes orphaned and overprivileged identities visible.

A CISO starts with automated discovery across cloud platforms, SaaS applications, code repositories, and CI/CD pipelines. Each identity enters a central inventory with an owner, privilege level, and last-used date. Risk scores then weigh exposure, privilege, credential age, and activity. Teams remediate the highest-scoring identities first and rescan continuously.

Oasis Security discovers NHIs and AI agents, risk-scores them, attributes them to human owners, and manages credential life cycles. The Zscaler Zero Trust Exchange inspects, brokers, and enforces machine-to-machine connections inline. They merge to form one unified control plane that can rotate secrets and block compromised connections in transit.

Governance finds and fixes risky identities, but a stolen token still works until someone revokes it. Inline enforcement inspects every connection as it happens. It applies policy to the identity, destination, and behavior, then blocks suspicious sessions in transit. Protection becomes real-time and independent of where a secret is stored.