Most security teams can name every human who has access to production. Very few can name every workload that does.

The identity governance review you commissioned last quarter will hand back a spreadsheet of employees and contractors. It will not contain the service account that runs your nightly inventory sync, the CI token that can write to your payments repository, or the API key your new support assistant uses to read order history. Those are non-human identities, and in most enterprises they now outnumber people by roughly eighty to one.

That ratio comes from GitGuardian's State of Secrets Sprawl report for 2026. The exact multiple is arguable; the direction is not. Every cloud service you adopt, every pipeline you wire up, every AI agent you pilot adds machine credentials. None of them require a laptop, a password reset, or an onboarding form. They get created by a developer on a Tuesday afternoon and forgotten by the following sprint.

What counts as a non-human identity

A non-human identity is any credential that authenticates a workload rather than a person. The category is wider than most teams assume:

• Service accounts running on VMs, containers, and internal APIs
• API keys and OAuth client credentials for third-party services
• CI/CD pipeline tokens and deployment keys
• Kubernetes service account tokens
• Cloud IAM role bindings and managed identities
• Agent configuration tokens for LLM and automation platforms
• Webhook signing secrets
• TLS certificates and their private keys

That list matters because most governance frameworks still measure the first category only, or none of them. Meanwhile the list keeps growing.

Why the sprawl got worse

The sprawl has three engines, and none of them are slowing down.

Agentic AI. Every agent needs credentials, usually several: a service account for the runtime, a key for the model provider, and a token for every tool it calls. Entro Labs measured a 44 percent year-over-year jump in the non-human identity population between 2024 and 2025 and tied it directly to agent adoption. A team that deployed a dozen agents last year did not add a dozen identities. It added something closer to forty.

Cloud migrations. Splitting a monolith into microservices multiplies the identity count, since each service needs its own identity and autoscaling creates dynamic credentials on a scale no manual register will capture. Providers doing this work typically see ten times the identities they started with.

Low-code platforms. Someone in marketing can now build an automation that holds a service account with read access to your CRM. Nobody in IT hears about it. The credential is real, the access is real, and it exists outside every control you built.

How the damage actually shows up

Sprawl is only the setup. Here is where it bites.

Orphaned credentials

When an employee leaves, HR triggers a chain of deprovisioning steps that cover their human account. Nothing triggers for the machine identities they created. Research published in 2026 found that 8 percent of enterprise identities have no HR ownership linkage at all after their creator departs. They keep working. They keep authenticating. They keep their permissions. Nobody notices until an incident review turns one up.

Over-privileged tokens

A token created to read a config bucket is rarely scoped to reading a config bucket. It gets created with the developer's ambient permissions, which are usually administrative, and nobody narrows the scope because nothing broke. This is the credential an attacker wants most. There is no MFA prompt to defeat, no impossible-travel alert to raise, and no login pattern that looks wrong. The workload authenticates the same way it did yesterday, from the same region, at the same volume. Your monitoring calls it routine.

Entro's research found that 47 percent of non-human identities had gone unchanged for more than a year. Credentials nobody rotates are credentials nobody reviews.

Secrets landing in code

GitGuardian counted 28.65 million hardcoded secrets added to public GitHub repositories in 2025, a 34 percent increase over 2024 and the largest single-year jump on record. More than 1.27 million of those were AI-related: model provider keys, agent configuration tokens, LLM service credentials. AI coding assistants make this worse in a quiet way. They suggest code that works, and code that works often has a key pasted in to make it work.

The counterintuitive part: internal repositories are six times more likely to hold hardcoded secrets than public ones. The repo you assume is safe because it is private is where the leaks concentrate.

What attackers do with them

A stolen human credential has a natural expiry built into human behavior. The victim eventually changes the password, or the session times out, or MFA prompts on a new device. A stolen machine credential has none of that. It works from anywhere, at any hour, until someone revokes it, and the attacker can read every secret the workload was allowed to reach, including the keys to other systems.

This is why machine credentials are the preferred first step in cloud intrusions now. They are also the hardest to detect after the fact, because the traffic they generate looks exactly like normal service traffic. Your egress monitoring logs it as routine. Nothing is anomalous about a service account querying the database it has always queried.

Why existing IAM tooling falls short

Legacy identity platforms were built around human lifecycle events: hire, role change, leave. Machines have none of those milestones. A workload authenticates thousands of times a day, runs at 3am, and never takes a vacation.

The survey numbers reflect that mismatch. A 2026 NHI Reality Report found that 78 percent of organizations have no documented policy for creating or removing AI identities. Only 8 percent of respondents expressed high confidence that their legacy IAM systems can handle AI and non-human identity risk. A separate World Economic Forum analysis put the number of organizations with no clear ownership of AI identities at 51 percent.

The gap is not tooling depth. It is that nobody is accountable for a class of credentials most teams cannot even enumerate.

What a workable program looks like

You do not fix this by buying a product. You fix it with a discovery pass, an ownership model, and a move away from static credentials. In that order.

1. Inventory before you govern

Pull every credential from your cloud providers, your secret manager, your CI/CD system, and your identity provider. Map each one to a workload and a human owner. The first pass will be uncomfortable; expect to find credentials for systems that no longer exist and keys for vendors you stopped using last year. That discomfort is the finding.

2. Attach an owner to every identity

Every machine identity needs a named owner and a stated purpose, the same way every employee has a manager. When that owner leaves, their identities must appear on an offboarding checklist. The WEF finding that half of organizations have no clear ownership of AI identities is the exact gap this step closes.

3. Stop storing long-lived secrets

The durable fix is to stop shipping static credentials at all. Workload identity federation lets a workload prove who it is using its platform's native attestation, such as a Kubernetes service account or an AWS IAM role binding, and receive a credential that expires in minutes.

SPIFFE and SPIRE extend the same idea to multi-cloud and hybrid environments. Each workload gets a verifiable identity with a short time to live, issued after attestation, and usable across trust domains. The enterprise migration path for this is well documented: stand up SPIRE, configure its OIDC federation endpoint, update cloud IAM trust policies to accept SPIRE-issued tokens, then move your broadest-permission workloads off stored credential files first.

Two benefits follow. A stolen credential is worthless within the hour. And every credential issuance leaves a verifiable record you can hand to an auditor, which turns an open finding into evidence.

4. Scope agent permissions separately

Treat the permissions you grant an AI agent as its own risk domain, not as an extension of the developer who built it. Give the agent the narrowest set of tools that lets it do its job and require a human checkpoint on anything irreversible: payments, deletions, access changes. If an agent's decision path touches money or permissions, it needs a brake that does not depend on the model behaving correctly.

5. Rotate on a schedule and alert on drift

Rotation should be an automated job, not a quarterly project. Build a view that flags identities with no recent rotation, no named owner, or permissions that grew after creation. Then alert on any credential that appears outside your provisioning path. A new unmanaged credential is what a compromise looks like before it becomes a breach.

The questions worth asking this quarter

Four questions separate a program that works from a policy document nobody reads.

• Can we produce a list of every machine identity with write access to production, with an owner for each?
• What is the average lifetime of a credential in our environment, and how many have never been rotated?
• If our highest-privilege service account were stolen tonight, how long before anyone noticed, and what could the attacker reach?
• Do the agents we have deployed run with permissions narrower than the engineers who built them?

If any answer is "we would have to check," you already know where the work starts.

Where to start

If a full inventory sounds like a six-month project, narrow it. Pick the three systems whose compromise would hurt most. That is usually your payment pipeline, your production database, and your customer data warehouse. Enumerate every identity that can reach them. You will find the credentials that matter inside a week, and you can start shortening their lifetimes while the complete inventory continues in the background.

Non-human identities are not going away, and every new agent adds more of them faster than any team can review by hand. The organizations that stay ahead of this treat machine identity as an inventory problem first and a technology problem second. Enumerate, assign an owner, expire the credential. The rest follows from those three.

Tech Hub Services builds and secures enterprise software, including identity architecture reviews and AI agent security assessments. If you cannot produce a list of every machine credential with access to production, that is the place to start. Contact Tech Hub Services at info@techhubservices.com or +1-289-831-7777.