What is Non-Human Identity Sprawl and How Do You Reduce It?

Every identity program built in the last decade was designed around a person. Someone gets hired, a record lands in the HRIS, provisioning fires, a manager signs off, and on their last day the whole thing unwinds. That model works. It's the one you've spent years tuning, and it now covers a shrinking share of the identities authenticating in your environment.

The rest are machine identities: service accounts set up at 2 a.m. to unblock a deployment; OAuth grants approved by a marketer for an unfamiliar tool; pipeline credentials minted for each branch; and agents that request access and spawn additional agents to complete a task. Often, no one files a ticket for any of it, and no process is scheduled to retire those identities.

So you run a scan, find a number that surprises you, spend six weeks chasing owners, and watch the next scan come back higher. This article explains why non-human identity sprawl compounds despite repeated cleanup, how to measure whether you're gaining or losing ground, and where to place controls so the population stops growing by default.

What is non-human identity sprawl?

Non-human identity sprawl occurs when machine credentials, service accounts, API keys, tokens, and AI agent identities accumulate faster than your team can inventory, attribute, or retire them. The reason cleanup efforts do not last isn't poor execution. It's that creation is often ungoverned and automated, while retirement remains manual.

Volume isn't sprawl. A platform team managing 40,000 service accounts, each with a named owner, a scoped permission set, and an expiry date, doesn't necessarily have a sprawl problem. A team managing 4,000 identities without knowing who owns them does.

Sprawl is the gap between the identities that exist in your environment and the identities you can account for. That gap is what auditors uncover, what attackers exploit, and what can widen every quarter whether or not you run a cleanup sprint.

The population is broader than most inventories capture. It includes service accounts and service principals, API keys and bearer tokens, OAuth grants issued to third-party apps, TLS and mTLS certificates, managed identities, CI/CD pipeline credentials, workload identities, RPA bots, and the fastest-growing entry on the list: AI agents.

What's the difference between non-human identity sprawl and secret sprawl?

Many teams undercount, and they often undercount in a predictable direction. Whatever your IdP reports is usually the floor, not the total, because identities created outside the IdP may never have been registered anywhere. Local accounts on databases, keys minted inside a build pipeline, and tokens issued by one SaaS app to another can all sit outside the directory you're reporting from. If your inventory comes from one source, assume it is incomplete.

Three terms are often used interchangeably, but they shouldn't be. Machine identity is the older, narrower term, rooted in certificates and TLS. Non-human identity is the umbrella term that also covers app-layer tokens, bots, and agents. Secret sprawl is a subset that describes the credentials themselves rather than the identities holding them. That distinction matters: Rotating a leaked key does nothing about an over-scoped service account that shouldn't exist.

The human version of this problem has a different shape. People accumulate too many accounts across too many apps, and the fix is consolidation. Machines accumulate accounts that no one claims, and the fix is attribution.

What causes non-human identity sprawl?

Non-human identities can be created by many teams but are often retired by no one. Four structural gaps allow the problem to persist, and additional cleanup effort alone does not resolve them.

Creation bypasses tickets

A new hire triggers an HR record, an IdP entry, and a provisioning workflow with an audit trail attached. A new service account may be created through a terraform apply. The Cloud Security Alliance found that more than 16% of teams don't track the creation of new AI-related identities at all, and fewer than a quarter have a documented policy for creating or removing them. You can't govern an event you never see.

No leaver event triggers retirement

This is the gap that matters most. A human has a last day, and that date propagates through every downstream process you've built over the past decade. A service account can outlive the project that needed it, the engineer who created it, and even the vendor it was integrating with. Traditional offboarding processes aren't designed to notice.

Ownership remains optional

The World Economic Forum reports that 51% of teams lack clear ownership for AI identities. Without an owner, no one can answer the question that must precede revocation: What breaks if this identity goes away? As a result, teams hesitate to revoke it. Fear of breaking production is a common reason dormant credentials survive audit after audit, and that fear is rational when the blast radius is unknown.

Retirement lacks a formal workflow

According to CSA and Astrix survey data, only 20% of organizations have a formal process for offboarding and revoking API keys, and fewer still have one for rotating them. Only 6% report full visibility into their service accounts. In many environments, retirement isn't a workflow; it is work someone takes on when time permits.

Put those four gaps together, and the arithmetic is fixed. Creation runs at machine speed while retirement runs at human speed, so the population compounds by default. Cleanup sprints don't change the equation. They reset the starting number and may buy you a quarter.

What non-human identity sprawl costs you before it costs you a breach

Three of the four costs of sprawl show up long before an incident does, which is exactly why they are often tolerated.

Audit drag

When an auditor asks who owns a service account with production write access and the answer requires three Slack threads and an educated guess, that's a finding. Sprawl converts directly into audit hours, and at scale it can escalate into the material-weakness conversation no one wants to have with the board.

The cost compounds because it is recurring. You pay it every SOX cycle, every SOC 2 renewal, and every time a customer's security questionnaire asks how you govern machine access. Teams using delta reviews, in which each cycle covers only what changed since the last one, have cut review cycles by 90% because they no longer relitigate the same unchanged entitlements four times a year.

Blast radius

Any unretired credential with standing privilege creates a live attack path whether or not anyone uses it legitimately. Many machine identities do not use MFA, so a stolen static secret can provide full access with no second factor to slow an attacker. The 2026 Verizon DBIR puts third-party breaches at 48%; an unreviewed OAuth grant is one access path that can contribute to that exposure.

Detection noise

Machine-to-machine traffic looks normal by definition. The more unaccounted-for identities running in your environment, the lower the signal in every alert your SOC triages. You can't baseline the behavior of an identity you didn't know existed.

Breach exposure

Sophos surveyed 5,000 security leaders across 17 countries for its 2026 State of Identity Security report and found that 71% had suffered at least one identity-related breach in the prior year, with an average recovery cost of $1.64 million and weak non-human identity management cited in 41% of incidents.

How to measure non-human identity sprawl

Stop counting what you cleaned up. Start counting what you created.

Most teams measure their non-human identity security strategy by remediation volume: accounts disabled, keys rotated, and entitlements stripped. That's a stock measurement applied to a flow problem, and it can tell you you're winning right up until the next scan says otherwise.

One ratio tells you the truth.

Sprawl ratio = non-human identities created this quarter ÷ non-human identities retired this quarter

Above 1.0, the population grows despite cleanup. At 1.0, the population is stable—a position many teams have not reached. Below 1.0, the attack surface is shrinking, and least privilege becomes an end state you can reach instead of a project that never closes.

‍

You can derive both numbers from data most organizations already hold. Pull creation timestamps from cloud IAM audit logs, IdP service account records, OAuth grant logs, and secrets manager entries. Pull retirements from deprovisioning records, revoked keys, and disabled accounts.

Many teams cannot produce the denominator on the first attempt, and that is itself a finding. If you can't count what you retired last quarter, your retirement process runs on audit season rather than on a schedule.

Two supporting measures sit underneath the headline ratio.

1. Unowned rate is the percentage of your non-human identities with no named human owner. The 51% figure cited above provides an uncomfortable benchmark.
2. Median credential age is the blunter measure: If the median static secret in your environment predates your last two audits, rotation isn't a program; it's an aspiration.

Report the ratio to your CISO instead of relying only on the cleanup count. It is a more durable indicator because it remains meaningful when the next quarterly scan arrives.

The four places non-human identities are created

Most non-human identities enter an environment through four common creation surfaces, and each can be governed at creation.

Much of the market focuses on discovery and remediation. Both matter, but cleanup alone cannot get ahead of a running tap.

1. Cloud IAM

Roles, service principals, and managed identities can be created by infrastructure-as-code workflows at deployment time, at machine speed, with no human in the approval path. Gate this surface by requiring owner and purpose tags in the module itself and enforcing that requirement in the pipeline. An untagged identity should cause the plan to fail rather than enter the environment without attribution. This control prevents unattributed identities from flowing through one of the highest-volume creation surfaces.

2. SaaS integrations and OAuth grants

A user can connect a third-party app to your tenant and grant it scopes on behalf of everyone. The connection may create no ticket, provide no administrative visibility, and leave a credential at the vendor rather than in your vault. This creation surface is easy to overlook and has appeared in prominent integration breaches. Enforce administrative-consent policies and continuously discover grants across every connected app. A policy that covers only known apps leaves blind spots.

3. CI/CD and pipelines

Build infrastructure mints credentials by environment, branch, and job. Ephemeral compute can leave non-ephemeral secrets behind, which is how a key created for a two-week project can remain valid three years later. Replace static keys with workload identity federation so the credential expires with the job that needed it.

4. AI agents

Agents can request access dynamically, spawn subagents, and, in some deployments, provision their own credentials. Assumptions designed for static service accounts can fail here, and the governance gap is measurable: The 2026 NHI Reality Report found that 78% of teams have no documented policy for creating or removing AI identities. Treat each agent as a first-class identity with an owner, a defined scope, and an expiry from the moment it is deployed rather than retrofitting those controls after it is already running against production data.

Controlling all four creation surfaces gives teams a practical path to reducing the sprawl ratio below 1.0 because fewer identities enter the environment without ownership or an expiration date.

How to start reducing non-human identity sprawl in 90 days

Non-human identity prevention doesn't need a 12-month rollout that's obsolete before it finishes. Three moves in 90 days will beat it, and the sequence matters more than the pace.

• Weeks 1 to 4: Build the count first. Pull records for non-human identities from your IdP, cloud accounts, and connected apps into one inventory, including local and orphaned accounts, and then calculate your sprawl ratio. You need the baseline before you need the plan, and the number helps define the scope and support the budget request.
• Weeks 5 to 8: Attribute before you delete. Assign a named human owner to each identity in your highest-risk tier. Deletion should follow ownership. Deleting first can break production, weaken the mandate, and force the team to spend the next two quarters rebuilding confidence in the program.
• Weeks 9 to 12: Control the highest-volume creation surface. Identify which of the four creation surfaces produced the most net-new identities last quarter, and put a complete control on that surface. One fully implemented control is more valuable than four partial controls.

This plan does not require a two-year program. A modern identity platform can be deployed in under three months, often in less time than teams spend scoping a cleanup project.

Why companies use Lumos for non-human identity governance

A durable program governs machine identities in the same platform, on the same schedule, and with the same reviewers as human identities. Lumos is designed around that model. The platform brings discovery, ownership, and review into one workflow for non-human identity governance.

Every non-human identity lands in one inventory

Discovery runs continuously across your identity provider, cloud infrastructure, and SaaS apps, including the service accounts, agents, workload identities, and tokens created outside the directory. That coverage matters because directory-only inventories miss identities created elsewhere. ChargePoint connected more than 100 apps in under three months and gained visibility into unused and orphaned accounts that had been difficult to see.

Every service account gets an accountable human

Ownership is attached when an identity is first discovered, so a responsible person is identified before the next review. Identity security agents continuously monitor service accounts, API keys, and tokens and route dormant or over-scoped identities to their owners instead of leaving them in a quarterly queue.

Machine access gets reviewed alongside human access

Non-human identities enter the same certification campaigns as employee identities, so app owners can see human and machine access side by side and revoke access or rotate credentials from within the review. Delta reviews make this manageable at scale by surfacing only what changed since the last cycle. Pluralsight went from reviewing 20 apps over two months to 200 apps in under two weeks, allowing reviewers to focus on exceptions instead of repeatedly reviewing unchanged access.

Stop cleaning up non-human identity sprawl and start preventing it

You have automated your infrastructure, deployments, and release pipeline. The identities running those systems remain one of the last populations that are often created without a formal request and retired without a formal trigger.

Every quarter spent cleaning up is another quarter during which the tap remains open. Your first sprawl-ratio calculation may confirm what you already suspect, which is a strong reason to calculate it now. Teams that make progress stop measuring only what they removed and start governing what gets created.

Lumos is built to support that shift. Every service account, API key, token, and agent can receive a human owner when it is discovered; machine access can move through the same review campaign as employee access; and dormant or over-scoped identities can surface before an auditor or attacker finds them. Book a demo to see what Lumos finds in your environment.

‍