The NHI Explosion: Why Non-Human Identities Are the Identity Blind Spot of 2026

NHIs outnumber humans 45:1 in the average enterprise - and 97% carry excessive privilege. Here's what's driving the crisis, what the Vercel and Salesloft Drift breaches teach us, and a 5-step path to governance.

9 min read · Last updated June 2026

Your identity program governs thousands of human accounts. It almost certainly does not govern the hundreds of thousands of non-human identities sitting alongside them - and attackers have noticed.

The average enterprise now hosts over 250,000 non-human identities (NHIs) across its cloud environments, according to the [1]. Research from Rubrik Zero Labs puts the NHI-to-human identity ratio at 45:1 in the modern enterprise; for cloud-native and DevOps environments, [2] puts that figure at 144:1. A Fortune 500 company can easily cross 500,000 machine identities. Every one of them authenticates continuously, accesses sensitive systems, and carries permissions that would trigger an immediate review if a human account held them.

The governance programs built to manage those human accounts were never designed for this.


What "Non-Human Identity" Actually Means

The term covers a wide and growing taxonomy. Non-human identities include service accounts, API keys, OAuth tokens, SSH keys, RPA bots, cloud workload credentials, and AI agents - the fastest-growing, least-governed attack surface in the modern enterprise.

In practice, NHIs fall into a few operational categories:

  • Service accounts - long-lived credentials created for applications, scripts, and scheduled jobs. Often provisioned with broad permissions "to avoid friction" and rarely reviewed.
  • API keys - static secrets embedded in code, CI/CD pipelines, and configuration files. Frequently committed to repositories and forgotten.
  • OAuth tokens - delegated access grants issued when a user or admin connects one SaaS app to another. Refresh tokens can persist indefinitely after the original authorization.
  • AI agents - the newest and fastest-growing category. Unlike static service accounts, an AI agent operating with delegated access may dynamically escalate its scope in ways no policy document anticipated. The blast radius is substantially higher, and the audit trail substantially thinner.

What unites all of them: no HR record, no MFA, no password reset cycle, and no one whose job it is to notice when they go stale.


The Structural Reason NHIs Escape Governance

Most identity governance programs are built on a simple assumption: identities represent people. IGA platforms were designed around the idea that human identities have clear authoritative sources, relatively stable attributes, and predictable joiner-mover-leaver events. Non-human identities violate nearly all of these assumptions. They may be created ad hoc by any line of the business, initiated in cloud platforms, or generated by automation tools.

The JML automation that works well for employees - HRIS event fires, SSO account provisions, SCIM pushes downstream - simply has no trigger for a service account a developer created last Tuesday. Unlike human employees who have a "Joiner-Mover-Leaver" process tied to HR, NHIs are often created ad hoc by developers. There is no hire record. No termination event. No offboarding workflow. The account just sits there, accumulating access, until something goes wrong.

SSO doesn't close this gap either. SSO governs login for human users. It has no visibility into the OAuth grants those users authorize, the API keys their applications generate, or the service accounts their CI/CD pipelines create. Governing human identities through SSO while leaving NHIs unmanaged is like locking the front door and leaving the server room open.

warning Warning

SSO is not governance. SSO controls how humans log in. It has no visibility into OAuth tokens, API keys, or service accounts created outside the IdP. An enterprise with 100% SSO coverage can still have 250,000+ ungoverned NHIs.


The Numbers Are Alarming - and Getting Worse

The scale of the problem is now well-documented in 2026 research:

According to the [3] - a vendor-agnostic survey of 5,000 IT and cybersecurity leaders across 17 countries - 71% of organizations suffered at least one identity-related breach in the past year.

[3] - including API keys stored in code, static credentials, and orphaned service accounts - was cited as a contributing factor in 41% of those incidents.

Organizations with weak NHI management are [4] and pay approximately $147,000 more to recover than the average breach victim.

The credential hygiene picture is equally stark. 97% of NHIs carry excessive privileges beyond what their function requires, and 71% have not been rotated within recommended timeframes. 47% of NHIs are more than one year old with no credential rotation. Only 1 in 3 organizations regularly rotates or audits service accounts and non-human identities, and just 11% do so continuously.

The dwell-time problem compounds all of this. The average dwell time after an NHI breach is over 200 days - more than three times the average for compromised human accounts. An API key never notices suspicious activity. It just keeps authenticating.

NHI Governance: The State of Play in 2026

Two Breaches That Made the Abstract Concrete

Salesloft Drift - August 2025

In August 2025, Salesloft's Drift chatbot service became the conduit for one of the largest SaaS supply-chain breaches to date. Drift integrates with customer systems such as Salesforce, Slack, and Google Workspace via OAuth tokens. Threat actors exploited this integration to steal authentication tokens and gain access to customer environments. More than 700 organizations were affected, including high-profile vendors such as Cloudflare, Zscaler, Palo Alto Networks, and PagerDuty.

Between August 9 and 17, 2025, the intrusion cluster tracked as UNC6395 exploited stolen OAuth tokens from Salesloft's Drift chatbot integration to gain access to hundreds of Salesforce environments. Over a ten-day period, the attackers systematically queried and exported large volumes of records from more than 700 organizations. Stolen records were combed for plaintext AWS keys, VPN credentials, Snowflake tokens, and other secrets that could enable follow-on compromises.

The root cause: the breach stemmed from weak credential management, over-permissive integrations, and lack of monitoring, rather than a direct exploit of Salesforce. The OAuth tokens connecting Drift to customer Salesforce instances were the attack surface. No one was governing them.

Vercel / Context AI - April 2026

In an intrusion that began with a Lumma Stealer malware infection at Context.ai in approximately February 2026 and was disclosed in April 2026, attackers leveraged a compromise of Context.ai's Google Workspace OAuth tokens to gain a foothold into Vercel's internal systems, exposing environment variables for an undisclosed but reportedly limited subset of customer projects.

The attacker used those credentials to silently access the Vercel employee's Google Workspace account - bypassing multifactor authentication entirely, because OAuth tokens, once issued, do not require re-authentication. Via Google single sign-on, the attacker moved into Vercel's internal systems - issue trackers, admin tools, and internal environments. The attacker then bulk-extracted environment variables from Vercel customer projects: the secrets and credentials companies store in Vercel to make their applications work.

An all-too-common tale in the modern enterprise: the SaaS app that was trialled by a single employee, lightly used, integrated with core app tenants, and forgotten about - adding an invisible node to the organization's attack surface. Vercel is not even a Context customer - at least one Vercel employee signed up for the AI Office Suite using their Vercel enterprise account and granted "Allow All" permissions. Vercel's internal OAuth configurations appear to have allowed this action to grant these broad permissions in Vercel's enterprise Google Workspace.

Both breaches share the same structural failure: OAuth tokens and third-party integrations - classic NHIs - operating completely outside any governance framework.


The AI Agent Multiplier

Every AI agent your organization deploys creates new NHIs. AI agents can autonomously spin up sub-agents, each generating new credentials with broad, persistent access and inconsistent human oversight. AI magnifies existing NHI risks related to governance, visibility, ownership, and credential lifecycle management. Most organizations still manage AI identities using legacy IAM tools and manual processes - but these resources were never designed for autonomous, high-velocity systems. As AI-driven workloads accelerate identity creation, organizations struggle with credential sprawl, unclear ownership, inconsistent automation, and slow remediation timelines.

[5], yet 78% expect NHI growth to outpace human identity growth over the coming year. The gap is widening, not closing.

The governance challenge for AI agents is qualitatively different from static service accounts. A service account has a defined scope you can inventory and audit. An AI agent operating with delegated access may dynamically escalate that scope. It may spawn child agents. It may write to production systems over a weekend while no detection rule fires - because no one defined what anomalous agent behavior looks like.


The Path to NHI Governance

The good news: this is a solvable problem. It requires treating NHIs with the same lifecycle rigor applied to human identities - discovery, classification, least-privilege enforcement, rotation, and decommissioning - in a single governance plane.

Here's a practical five-step path:

1
Discover and inventory every NHI

You cannot govern what you cannot see. Scan across your SaaS stack, cloud environments, CI/CD pipelines, and code repositories for service accounts, API keys, OAuth grants, and bot credentials. Include third-party integrations — the Vercel and Salesloft Drift breaches both originated in OAuth connections that were never inventoried. Assign an owner to every NHI found.

2
Classify by risk and function

Not all NHIs carry equal risk. Classify each by sensitivity of the systems it accesses, breadth of permissions, credential age, and whether it has a known owner and active use case. Orphaned NHIs — those with no active parent process or human owner — should be treated as critical risk and revoked immediately.

3
Enforce least privilege and right-size permissions

97% of NHIs carry excessive privilege. Audit the actual permissions each NHI uses versus what it holds, and strip everything beyond operational necessity. For OAuth grants, review scopes — most third-party tools request far more access than they need. For AI agents, define explicit permission boundaries before deployment, not after.

4
Replace long-lived credentials with short-lived, policy-driven access

Static API keys that never expire are the single biggest NHI risk factor. Move toward short-lived credentials with automatic expiry, workload identity federation where possible, and policy-driven issuance that ties credential scope to a specific function and time window. Every NHI should have a defined lifecycle — creation, rotation, and decommissioning — enforced automatically.

5
Govern human and non-human identities in one plane

Siloed tools — one for human IGA, another for secrets management, another for OAuth visibility — create the coverage gaps attackers exploit. A unified governance layer that applies consistent policy, audit, and lifecycle automation across all identity types closes those gaps and makes compliance attestation tractable. This is the architecture that makes NHI governance sustainable at scale.


Why Unified Governance Is the Only Durable Answer

Point solutions for NHI security - secrets managers, OAuth auditors, cloud CIEM tools - each address a slice of the problem. But the Salesloft Drift and Vercel breaches didn't exploit a gap in secrets management or cloud configuration. They exploited the absence of any governance at all over a class of identities that nobody owned.

The durable answer is a governance platform that treats human and non-human identities as two populations of the same problem: who has access to what, is that access still appropriate, and what happens when it isn't. That means fine-grained, policy-driven control at the level of individual tokens, OAuth scopes, and agent permissions - not just coarse role assignments. It means lifecycle automation that covers the full stack, including the long tail of SaaS apps that don't support SCIM. And it means continuous visibility, not quarterly reviews.

For security leaders and platform engineers building toward this, the question isn't whether to govern NHIs - the breach data makes that case conclusively. The question is whether your current IGA platform was built to handle them, or whether it was built for a world where every identity had an HR record.

Most legacy IGA platforms were built for the latter. The non-human attack surface your service accounts and API keys represent and the structural differences between NHI governance and traditional IGA are worth understanding in depth before you evaluate your options.


The Window Is Closing

Attackers are increasingly targeting machine identities and authenticated session artifacts in addition to traditional credentials. "We're witnessing a structural shift in how identity is exploited," said Trevor Hilligoss, Chief Intelligence Officer at SpyCloud. "Attackers are no longer just targeting credentials. They're stealing authenticated access - including API keys, session tokens and automation credentials - and using this access to move faster, stay persistent."

The enterprises that get ahead of this aren't waiting for the next Vercel-scale incident to justify the investment. They're building governance programs that cover every identity - human and non-human - in a single, auditable, policy-driven plane.

Related reading