In the average enterprise, non-human identities outnumbered human ones 92 to 1. Entro Security’s H1 2025 research put that ratio at 144 to 1 a year later. This isn’t a static fact about how many service accounts a company happens to run. It’s a growth rate, and most identity management programs were built around a review cycle designed for people, not for a population of credentials multiplying faster than any quarterly audit can keep up with.
Non-human identity sprawl is what happens when that growth rate outpaces an organization’s ability to track, own, or retire what it created. The human identity side of this problem is decades old and reasonably well understood. What’s changed the shape of it in 2026 is agentic AI, and specifically, the non-human identity sprawl created by systems that generate credential relationships as a side effect of doing their job, not as a deliberate provisioning event anyone signed off on.
A non-human identity is any credentialed entity that authenticates and acts without a person typing a password at the moment of access: service accounts, API keys, OAuth tokens, automation credentials, container and virtual machine identities, and, the category growing fastest right now, AI agent and MCP server identities.
The distinction that actually matters isn’t technical; it’s organizational. A human identity has a person accountable for it who can be asked why it exists, what it’s for, and whether it still needs the access it has. A non-human identity frequently doesn’t. It was provisioned by someone who has since changed teams, or generated automatically by a pipeline, or spun up by a developer solving an immediate problem with no expectation that anyone would need to explain it eighteen months later. Human identity sprawl barely exists as a comparable phenomenon precisely because HR onboarding and offboarding catch most of it by default; non-human identity governance starts from the absence of that same default catch, not from a technology choice.
Why Human Access Management Controls Don’t Map to Machine Identities
Traditional identity governance assumes a specific rhythm: onboarding with a defined start date, periodic access reviews where a human notices something looks wrong, offboarding tied to an employment event that triggers cleanup. That rhythm depends on a person being present at each stage to actually notice.
A machine identity doesn’t notice anything. It doesn’t flag its own excessive permissions during a review, because there’s no moment where it reflects on whether it still needs what it was given. It just keeps the access until someone actively revokes it, and in most organizations, nobody is assigned to do that as a routine task the way an HR system triggers offboarding for a departing employee. Non human identity access sprawl is what accumulates in that gap: not malicious over-provisioning, just the absence of the same forcing function human accounts get by default.
The numbers describe exactly this failure mode. Entro Security’s H1 2025 research found that 97% of non-human identities carry excessive privileges, and 71% are not rotated within recommended timeframes. Neither figure implies anyone decided lax secure access was acceptable. Both describe what happens automatically when nothing in the system forces the review a human account gets whether anyone remembers to schedule it or not.
A separate study makes the same point from the breach side rather than the audit side. Sophos’s State of Identity Security 2026, surveying 5,000 IT and cybersecurity leaders across 17 countries, found that 71% of organizations suffered at least one identity-related breach in the past year, and weak management of non-human identities specifically was the root cause behind 41% of those successful breaches. Only 34% of the same organizations regularly audit or rotate their service accounts and NHIs at all. That’s a different 71% than Entro’s rotation figure above, one measuring breach outcomes rather than audit compliance, and the two numbers point at the same underlying gap from opposite ends: most identities aren’t reviewed, and most organizations have already paid for that in a real incident.
Non-human identity sprawl causes in large organizations trace back to this same structural gap far more often than to any single bad decision: workload identities provisioned for a one-off task that never got a deprovisioning step, credentials copied from one service to another because it was faster than requesting new ones, shared secrets that outlived the project they were created for by years.
Where AI Agents and MCP Servers Expand the Attack Surface
Every general description of NHI sprawl treats AI agents as one more entry on a list that already includes service accounts and API keys. That undersells what’s actually different about them. A service account is provisioned once, for a defined purpose, and then sits mostly static until someone remembers to review it. An AI agent generates new credential relationships continuously as a side effect of normal operation: every tool invocation, every API call it makes on a task’s behalf, and every MCP connection it opens is itself a piece of non-human identity sprawl in AI systems, created at the pace the agent works, not at the pace an IAM team can provision and review. Agent identities compound this further once an agent spawns sub-agents or delegates tasks: each delegation is a new identity relationship, not a reuse of the original one.
An MCP server specifically is close to a textbook example of an unmanaged NHI, not an edge case of one. It’s a standing process with its own credential, frequently stood up in minutes by a developer who needed an agent to reach an internal system and had no reason to loop in a security review to do it. What that server, and by extension whatever agent connects to it, can actually touch is determined by only the access the credential happens to carry, and that access is routinely broader than the specific task required, because scoping a credential narrowly takes more time than reusing whatever was already lying around.
We’ve covered the full mechanism behind exactly this pattern, how a shadow MCP server actually gets created, why the credential it inherits tends to be broader than the task needs, and what a real discovery and remediation process looks like, in our dedicated piece on shadow MCP servers. In NHI terms, that entire mechanism is one specific, fast-growing instance of the broader sprawl problem: an identity nobody assigned an owner to, carrying access nobody scoped deliberately, that will keep existing until someone goes looking for it.
The Infrastructure Response
Any governance framework, including the one later in this piece, only works if the identities it governs are actually centralized somewhere a team can act on. An inventory of non-human identities nobody can query, scope, or revoke from one place is the same failure mode we’ve described in the context of MCP sprawl generally: visibility without a control point to act on it doesn’t close the gap, it just documents it. For the MCP-shaped slice of this problem, which is our platform’s focus, Obot approaches it as an Enterprise AI Control Plane built around three jobs: define what agents can reach, choose where they run, and prove what they did.
Gateway: Define What Agents Can Reach
That’s a structural, not a policy, fix. Obot MCP Gateway is open-source (MIT license), self-hostable on Kubernetes or Docker, and also available as a managed service. Same product either way. OAuth 2.1 gets brokered centrally, so a credential is issued, scoped, and revocable from one control point instead of typed into a developer’s config file and forgotten. Every connected MCP server becomes a named, ownable entity in a single catalog rather than an anonymous process running somewhere on a laptop. Every tool call gets logged at the individual request level, the continuous, action-level visibility a quarterly access review structurally cannot provide. Since v0.27, Okta SCIM provisioning also revokes access automatically when someone leaves, the offboarding trigger non-human identities usually lack.
Device: Watch and Enforce With Obot Sentry
A catalog only covers servers someone registered. The MCP servers described above, stood up in minutes on a developer’s machine, are the non-human identities nobody registered. Obot Sentry scans AI client configurations across Claude Code, Claude Desktop, Codex, Cursor, and VS Code, reports which MCP servers, skills, and plugins each machine loads, and can fail closed on servers that aren’t approved, so an unowned identity shows up in an inventory instead of surviving every review.
Hosted: Claude Environments
Obot v0.27 added Claude Environments, hosted Claude Code environments that run under the same control plane, so an agent’s connections come from policy rather than credentials copied into a local config file.
That’s identity lifecycle management applied at the layer where a meaningful share of new non-human identities are being created right now, not a retrofit years after the sprawl already happened.
The version of non-human identity sprawl that cloud-native enterprise teams are wrestling with stopped being purely a vendor talking point on January 8, 2026, when NIST issued a formal Request for Information on security considerations for AI agent systems, published in the Federal Register. A standards body soliciting public input on how to secure agentic systems is a specific, dated signal that this has moved onto a federal agenda, not evidence of what any eventual requirement will say. On February 17, 2026, NIST’s Center for AI Standards and Innovation followed with the AI Agent Standards Initiative, which includes work on agent identity and authorization. NIST hasn’t published a finalized framework as of this writing, and speculating about what one might eventually require would be exactly the kind of false confidence a technical reader has no reason to trust. What’s verifiable is narrower and still worth stating plainly: the request exists, it’s dated, and it’s specific to agent systems rather than NHIs generally, which tells you where federal attention is currently pointed.
A Practical Access Control Framework: Automated Lifecycle Management and Anomaly Detection
Most published advice on this topic converges on a similar shape: define, assess, enforce, detect, automate. That’s a reasonable skeleton, and it applies whether the identities in question sit in on-premises infrastructure or cloud environments. What it needs, and what most versions of it skip, is a priority order grounded in where the failure actually starts. Each step below maps to a control described in the infrastructure section above.
Assign ownership before provisioning, not after. Every NHI, an MCP server included, should have a named owner and a stated purpose at the moment it’s created, not discovered during a security audit six months later. An identity nobody can explain is the one that survives every review cycle unnoticed, precisely because nobody’s job depends on accounting for it.
Default to short-lived, brokered credentials over static ones. A compromised credential with a defined expiry limits the blast radius by design. A static, long-lived API key sitting in a config file doesn’t, and it’s a pattern that shows up repeatedly in credential exposure cases in NHI-related incident writeups. Scoping matters as much as lifespan: a credential limited to the specific tools it needs, rather than blanket server-level access, is covered in more depth in our guide to fine-grained MCP access control.
Log at the level of individual actions, not periodic snapshots. Continuous monitoring paired with anomaly detection on what an identity actually does, not just what it’s theoretically permitted to do, is what surfaces drift between granted access and used access before that gap becomes the thing an attacker exploits.
Build revocation into the lifecycle from day one. Deprovisioning shouldn’t be a cleanup project triggered by an audit finding. Automated lifecycle management should treat it as a defined step in how every non-human identity gets created in the first place, with an end condition specified up front rather than assumed to happen eventually.
None of this is complicated individually. Together, across a machine identity population that already outnumbers human identities 144 to 1 and keeps growing, it’s the difference between a governance program that scales with the problem and one that permanently chases it from three quarters behind.
FAQs
What is non-human identity sprawl?
Non-human identity sprawl is the uncontrolled growth of machine credentials, service accounts, API keys, tokens, and AI agent or MCP server identities, faster than an organization can track, own, or retire them. Non-human identities now outnumber human identities 144 to 1 in the average enterprise, up from 92 to 1 a year earlier.
How does Obot help with non-human identity sprawl?
For the MCP slice of the problem, Obot MCP Gateway brokers OAuth centrally so every MCP connection is a named, scoped, revocable identity with tool-call-level logging, and Obot Sentry finds MCP servers configured on employee machines that never went through registration at all.
What counts as a non-human identity?
Service accounts, API keys, OAuth tokens, automation and CI/CD credentials, container and virtual machine identities, and AI agent or MCP server identities. The defining feature isn’t the technical mechanism; it’s that the identity authenticates and acts without a person present at the moment of access.
How many non-human identities does the average enterprise have compared to human ones?
Entro Security’s H1 2025 research found a ratio of 144 non-human identities for every human identity, up from 92 to 1 the year before. That’s a growth rate, not a fixed number, and most identity governance programs weren’t built to track a population expanding that quickly.
Why don’t traditional IAM controls work for non-human identities?
Traditional IAM assumes a human present at onboarding, periodic review, and offboarding, each stage relying on a person to notice something is wrong. A non-human identity doesn’t notice anything on its own; it keeps whatever access it was given until someone actively revokes it, which is why 97% of NHIs carry excessive privileges and 71% aren’t rotated on schedule.
How do AI agents and MCP servers contribute to NHI sprawl?
An AI agent generates credential relationships continuously as a side effect of normal operation, every tool call and every MCP connection is itself a non-human identity. An MCP server specifically is typically a standing process with its own credential, often provisioned quickly with no assigned owner or defined lifecycle.
What are the main causes of non-human identity sprawl in large organizations?
The recurring pattern is credentials created for a specific task that never get a deprovisioning step, access scoped broadly because narrow scoping takes more time than reusing an existing credential, and no default forcing function requiring anyone to explain why a given identity still exists.
How is non-human identity sprawl different in cloud-native environments specifically?
Cloud-native and hybrid environments multiply the provisioning surface: containers, serverless functions, CI/CD pipelines, and workload identity federation across multiple cloud providers each generate their own credentials, often through automated processes with no single team reviewing the aggregate total across every environment.
How do you start reducing non-human identity sprawl?
Start with ownership, not cleanup: require a named owner and stated purpose at the moment any non-human identity is created, favor short-lived brokered credentials over static ones, log individual actions rather than relying on periodic snapshots, and build revocation into the identity’s lifecycle from creation rather than treating it as a later audit task.
