Key Takeaways
- NHIs already outnumber human identities in most enterprises, with reported ratios from 45:1 to over 80:1.
- The 2025 Salesloft Drift breach hit 700+ organizations through a single over-trusted OAuth token, no human error needed.
- Traditional IAM assumes a human logging in. NHIs need their own discovery, ownership, and monitoring practices instead.
- AI agents are the least governed category: 68% of organizations lack AI identity controls, and 47% can't secure shadow AI.
- A real NHI security strategy starts with discovery and ownership, then adds least privilege, credential rotation, and behavioral monitoring.
In August 2025, attackers didn’t break into Salesforce directly. They came in through Drift, a chatbot integration built by Salesloft, using compromised OAuth tokens associated with Drift’s Salesforce integration. Google’s threat intelligence team later put the damage at more than 700 affected organizations. No phishing email, no cracked password, no human clicking the wrong link. Just one machine credential, trusted by another machine, doing exactly what it was authorized to do until someone else was holding it.
That’s the shape of the problem this post is about. Somewhere between “service account” and “API key” and “AI agent,” enterprises have built a second population of identities that vastly outnumbers their employees, and most security programs still treat identity as a people problem.
What Non-Human Identity Security Covers
Non-human identity security starts with a simple question: what counts as an identity in the first place? A non-human identity, NHI for short, isn’t tied to a person at all. It’s assigned to a piece of software, a device, or a workload, anything that needs to authenticate and act inside a system on its own, without someone typing a password. IBM’s own definition gets at the same thing: a non-human identity is “a digital identity attached to a bot, AI agent, app, service, workload, device or other nonhuman user.”
There’s a wide range under that umbrella. Service accounts let one application log into a database or another application on a recurring basis. API keys and OAuth tokens, the kind stolen in the Drift breach, let one service call another and prove it’s allowed to. Certificates and SSH keys are how machines authenticate to each other over encrypted channels. Then there’s the stuff running quietly in the background, cron jobs, RPA bots, CI/CD scripts, usually with standing access to production and nobody watching too closely. IoT and OT devices carry their own credentials on the network. And now AI agents, which don’t just hold credentials but actively decide which tools to call and which data to touch, are joining the list as their own category.
Most of these were never meant to be long-term residents of a network. A build pipeline needs a token for the ten minutes it takes to deploy code. A service account got created back in 2019 for a migration project. That project wrapped in 2020. Nobody cleaned up the account either, because cleanup isn’t anyone’s job in particular.
- Generates High-Confidence Alerts
- Disrupts Autonomous and AI-Assisted Attacks
- Extends Detection Across Hybrid Environments
How Many Are We Actually Talking About
Every vendor report on this topic has a ratio, and the ratios don’t fully agree. GitGuardian’s State of Secrets Sprawl report[1] puts NHI secrets at 45 times the number of human identities in DevOps environments specifically, and Oasis Security’s own published research[2] lands in roughly the same territory, citing machine identities outnumbering human identities “by over 45:1 in many enterprises.”
A 2025 survey of 2,600 security decision-makers across 20 countries, found a wider gap: more than 80 machine identities for every human one, a ratio that has nearly doubled since the same survey first measured it in 2022. Some industry roundups push past 90 to 1 depending on how liberally “identity” gets defined.
That spread isn’t just noise. It’s worth sitting with, because it says something true about the state of this field: nobody has a fully agreed method for counting the thing everyone agrees is a problem. A DevOps-heavy ratio measured against secrets in code repositories is not quite the same population as a broad enterprise ratio measured through a security leader survey, and a vendor selling NHI discovery software has some incentive to report a number that makes the gap look as large as possible. None of that makes the underlying trend fake. That 80-to-1 figure nearly doubling since 2022 is a real, sourced data point on its own. It does mean any single ratio quoted without its source and methodology should be read skeptically, including the ones in this post.
What the reports do agree on is direction and speed. Entro’s NHI and Secrets Risk Report[3] found a 44% increase in NHIs from 2024 to 2025. Whatever the exact ratio at any given company, the line is going up fast, and headcount isn’t the reason.
Why the Number Keeps Climbing
Cloud adoption is the obvious driver. Every container, serverless function, and managed service that spins up needs its own way to authenticate to everything else it talks to, and cloud-native architectures are built to spin those up automatically, at a pace no ticketing system was designed for. CI/CD pipelines compound it: a modern deployment might involve a dozen tools, each with its own token, each stitched into the next stage of the pipeline.
SaaS sprawl adds another layer. Every third-party app an employee connects to Slack, Google Workspace, or Salesforce, the way Drift was connected to Salesforce, creates an OAuth grant that persists until someone remembers to revoke it. Most organizations have no central register of which integrations are live, let alone what each one can access.
AI agents are the newest and least well understood addition. IBM[4] Fellow Sridhar Muppidi, the company’s VP and CTO for security, put the risk this way: “You give them the credit card, and you expect them to behave properly, but don’t be surprised by what you find out. Agents are very similar to that.” An agent that can call APIs, query databases, and take multi-step actions on its own isn’t just a credential sitting in a vault. It’s a decision-maker with a decision-maker’s blast radius, and in most organizations, it’s being deployed faster than anyone is writing policy for it.
And this isn't a one-time thing:
- Drift, 2025: one stolen OAuth token, 700+ organizations affected
- LiteLLM, March 2026[5]: a compromised CI/CD tool, 2,500+ companies and 434,000 pipelines exposed
What Goes Wrong: The Drift Breach, and Others Like It
The Salesloft Drift incident is worth walking through in more detail because it shows how ordinary the failure usually is. UNC6395, the threat actor Google tracked, didn’t need a zero-day. It used OAuth tokens that Drift had already been granted, walked into connected Salesforce instances, and ran systematic SOQL queries to pull case data out.
In a number of environments the attackers went further and grabbed AWS access keys, Snowflake tokens, and passwords that customers had left sitting inside Salesforce records and support cases, the kind of thing nobody thinks to treat as sensitive until it’s gone. Salesloft and Salesforce didn’t revoke the Drift tokens until August 20, 2025. The FBI’s indicators of compromise came out on September 12, nearly a month later. By then the access had already been used across hundreds of organizations for weeks.
Nothing about that chain required tricking a human. It required one over-trusted, long-lived credential connecting two systems that both assumed the other side was legitimate. That’s not a hypothetical scenario. It’s three specific entries on the OWASP Non-Human Identities Top 10, published in 2025[6]: overprivileged NHI, long-lived secrets, and vulnerable third-party NHI. The full list runs to ten categories, and the other seven, improper offboarding, secret leakage, insecure authentication, insecure cloud deployment configurations, poor environment isolation, NHI reuse across systems, and risky human use of NHI credentials, are just as real. They just weren’t what happened here.
Some of these show up constantly in the secret scanning research. GitGuardian’s numbers alone make the point[7]: 23.77 million secrets exposed on public GitHub repositories in 2024, up 25% from the year before. Seventy percent of the secrets researchers first found sitting in public repos back in 2022 were still live and usable when they checked again. Nobody had rotated them. And when GitGuardian looked at what those leaked tokens could actually do, the picture got worse: 96% of exposed GitHub tokens carried write access, and 99% of exposed GitLab keys had full or read-only reach into whatever they touched. These weren’t scoped-down, harmless credentials sitting exposed in code. They were, more often than not, full keys to the kingdom.
Why Human-Built IAM Doesn't Fit Machines
Most identity and access management programs assume a person is sitting at the keyboard. You type a username, a password, maybe get hit with an MFA prompt, and the session dies once you walk away from your desk. None of that maps cleanly onto a service account or an API key.
An NHI can’t complete an MFA push. It doesn’t get suspicious about a login from a new location either, because it has no judgment to apply in the first place. Most of the time it was provisioned by a script or a Terraform template, not an HR onboarding workflow, so there’s usually no ticket behind it and no manager attached to it.
Ownership, if it was ever assigned at all, tends to fall off somewhere along the way. When the project that created it ends, or the employee who set it up leaves, the credential usually just keeps working. Nobody offboards a service account the way they offboard a person, because nothing in most organizations’ processes is built to notice it exists.
The same 2025 survey of security decision-makers mentioned earlier asked about this directly, and the numbers don’t line up. 88% said the term “privileged user” applies only to human accounts in their organization’s policies. Meanwhile, 42% of the machine identities in those same organizations’ environments carried privileged or sensitive access. Put those two side by side, and the gap is hard to miss. It means nearly half of an organization’s highest-risk credentials sit outside the category of controls built specifically for high-risk credentials.
Building a Non-Human Identity Security Program: Where CISOs Should Start
There’s no single tool that solves this, and any vendor promising one deserves a skeptical follow-up question. What the more mature guidance across Oasis Security, and OWASP converges on is closer to a sequence than a product.
Start with discovery. You cannot secure what you haven’t found, and most organizations underestimate their NHI count by a wide margin the first time they actually run a discovery scan across cloud accounts, code repositories, and SaaS integrations.
Next comes ownership: every credential needs a named accountable person or team attached to it, not a generic service account with no one on the hook when it’s flagged. From there, least privilege has to be enforced and re-checked on a schedule, not granted once and forgotten, since permissions creep the same way they do for human accounts.
Credential lifecycle matters as much as discovery. Long-lived, static secrets are the pattern behind most of the incidents above. Short-lived credentials that rotate automatically fix part of that problem: a stolen token expires before an attacker gets much use out of it. But rotation alone doesn’t catch everything.
A credential can be scoped correctly, rotated on schedule, and still get misused, and the only way to catch that is by watching what it actually does, not just what it’s allowed to do.
That’s what behavioral monitoring is for: it doesn’t just check whether a credential is valid; it checks whether the account behind it, human or not, is acting like itself. A stolen but properly scoped API key can sail through every access control and still stand out the moment it queries a database it’s never touched before, at 3 a.m., from a network segment nobody recognizes. That’s the same instinct behind network detection and deception work more generally, the approach Fidelis takes to this exact problem: watch behavior, not permissions. The credential still looks perfectly valid. The behavior is the tell.
- The New Reality of AI-Driven Breaches
- The Visibility Gap That Puts CISOs at Risk
- Strategic Recommendations for CISOs
The Agent Problem Nobody Has Solved Yet
Everything above describes a discipline that was already struggling to keep pace with service accounts and API keys before AI agents entered the picture. Agents complicate it further because they aren’t static credentials with fixed permissions. AI agents can dynamically choose tools, chain actions, and interact with APIs, and make decisions based on model outputs. The same survey found that 68% of organizations surveyed lack identity security controls for AI specifically, and 47% said they can’t secure shadow AI usage inside their own environment at all.
There isn’t a settled playbook here yet, and I’d be skeptical of anyone claiming there is. Treating an agent’s credentials the same way you’d treat a service account is a reasonable starting point, but it misses the part of the risk that comes from the agent’s own decision-making, not just what it’s authorized to touch. That’s an open problem, not a solved one, and the vendors currently marketing “AI identity governance” platforms are mostly building the plane while flying it, same as everyone else.
Where This Leaves Security Teams
None of the individual pieces here are new. Over-privileged service accounts, forgotten API keys, and unrotated secrets have been on audit findings for a decade. What’s changed is the scale and the speed, cloud infrastructure, SaaS integrations, and now autonomous agents are creating machine identities faster than most organizations can inventory them, let alone govern them. The Drift breach didn’t happen because a novel attack technique appeared. It happened because a trusted, ordinary OAuth connection sat unmonitored long enough for someone else to use it. That’s the pattern to watch for, not the exception.
That’s also where visibility does the real work. Watching what an identity actually does, not just what credentials it holds, is the same principle behind network detection and deception technology, which is the approach Fidelis takes to spotting behavior that doesn’t match a system’s normal pattern, whether the account behind it belongs to a person or not. It’s not a substitute for an actual NHI discovery and governance program. It’s what catches the moment a trusted connection stops behaving like one.
Frequently Asked Questions
What is a non-human identity?
Any digital identity used by software, a device, or a workload to authenticate and act within a system, rather than by a person. Service accounts, API keys, OAuth tokens, certificates, bots, and AI agents all fall under this category.
Why are non-human identities growing so fast?
Cloud infrastructure, CI/CD pipelines, and SaaS integrations generate machine credentials automatically. Entro’s research found a 44% year-over-year increase in NHIs from 2024 to 2025.
What's the biggest security risk with NHIs?
Overprivileged access, long-lived secrets, and vulnerable third-party NHIs, three of the categories in OWASP’s NHI Top 10, and exactly what enabled the Salesloft Drift breach: one over-trusted, long-lived credential connecting two systems that each assumed the other was legitimate.
How is securing an AI agent different from securing a service account?
A service account has fixed, predictable permissions. An AI agent can chain tool calls and take actions its developers didn’t explicitly script, so the risk includes what it decides to do, not just what it’s authorized to access.
Where should a company start building an NHI security program?
Discovery first, since most organizations undercount their NHIs badly. Then assign ownership to every credential, enforce least privilege on a schedule, move to short-lived rotated credentials, and add behavioral monitoring to catch misuse.
