Walk into almost any modern engineering organization and ask a simple question: who owns the CI runner token that can push to production? In most companies, the honest answer is a shrug. Someone created it years ago, it lives in a secrets store, three pipelines depend on it, and the person who set it up has since changed teams. It is not in anyone’s job description. It is not in the IAM review. It is, for all practical purposes, ungoverned — and it can deploy to your most sensitive environment.
That token is a non-human identity, or NHI. And it is not alone. For every human who logs in at your company, there are now tens of identities that never log in at all: service accounts, IAM access keys, OAuth-connected SaaS apps, signing certificates, workload identities, and — increasingly — AI agents and the MCP servers they call. The ratio has quietly inverted. The org chart describes a fraction of who, and what, can actually act inside your systems.
Why the human-IAM stack misses them
Identity tooling was built around a person. It assumes a joiner, a mover, and a leaver. It assumes a manager who can attest that someone still needs access. It assumes a login event, a session, an MFA prompt — a human in the loop who can be asked, “do you still need this?” None of those assumptions hold for a machine identity.
A service account has no manager to attest for it. An OAuth app does not get deprovisioned when an employee leaves; it keeps its grant and its scope until someone notices. An IAM key does not expire because a project ended. The result is that the controls your organization is proudest of — access reviews, joiner-mover-leaver automation, MFA — simply route around the majority of the identities that can touch production. The human plane is well-governed. The machine plane is mostly dark.
The org chart describes a fraction of who — and what — can actually act inside your systems.
Sprawl is not one problem; it is seven
It is tempting to treat “NHI sprawl” as a single inventory gap. It is not. Each class fails differently. CI/CD tokens accumulate broad, standing privilege because narrowing them risks breaking a pipeline nobody wants to touch. OAuth apps concentrate risk in third parties whose own security you cannot see. IAM keys leak into source code and stay valid long after exposure. Signing certificates can mint trusted artifacts and are almost never lifecycle-managed. Service accounts inherit privilege through role chains that no human ever reads end-to-end.
And then there are the new entrants. AI agents act with delegated authority, often across several hops. MCP servers sit in the path between an agent and the tools it invokes. These are not hypothetical — they are in production estates right now, and they were born into the same ungoverned plane as everything else. Treating all of this as one list to “clean up” misunderstands the shape of the problem.
Ownership is the missing primitive
The first move is not to delete anything. It is to make every machine identity attributable to a human owner and a stated purpose. An identity with a named owner can be reviewed, attested, and — when the time comes — retired with confidence. An identity without one is a liability that compounds quietly until it appears in an incident timeline.
This is the work TrustFix is built around: discovering every non-human identity across your clouds and code hosts, ranking them by what they can actually reach, and attaching ownership and a verifiable trust record to each. We are honest about the boundary here. Discovery and governance shrink the dark surface and make decay visible; they do not, on their own, prevent a determined insider or an upstream provider from misusing a grant that was legitimately issued. What they do is end the shrug — so that the next time someone asks who owns the production deploy token, there is an answer, and a signed record behind it.
Where to start this quarter
You do not need a year-long program to make progress. Start by inventorying the identities that can reach your most sensitive systems — payments, customer data, the production deploy path — and assign each one an owner and an expiry expectation. Treat anything that can sign, deploy, or read sensitive data as in-scope regardless of whether a human ever touches it.
The goal of the first quarter is not zero risk. It is to convert “no one owns them” into “every one of them is owned, reviewable, and on a clock.” That single change turns an invisible, ever-growing surface into something your organization can actually govern.