Every NHI program we have watched — including our own early attempts — follows the same curve. Discovery goes well. The inventory grows faster than anyone expected. Then the first remediation ticket comes back with a single line: who owns this? And the program stalls.
Why ownership is where programs stall
A human identity arrives with an owner built in: the person. When they leave, HR tells the directory, the directory tells the applications, and access ends. Machine identities have no such lifecycle. They are created by an engineer in a hurry, named after a ticket or a team that has since been reorganized, and they keep working long after the people who understood them have moved on.
So when a scanner flags a long-lived key, or a posture tool flags an admin role, the finding is correct and unactionable at the same time. Rotating the key without knowing what depends on it is an outage waiting to happen. Scoping the role without knowing its purpose is a guess. Deleting the identity is the bravest option and the one nobody takes.
This is why we say ownership is the control. It is not a metadata field to fill in after the real work is done. It is the precondition for every other control: rotation, scoping, offboarding, attestation and — for AI agents — approval of high-impact actions. An approval workflow with no approver is a denial workflow.
What ownership actually means
Ownership is often conflated with creation. The engineer who created a service account three years ago is a useful lead, not an owner. We use a narrower definition: the owner is the person or team who can answer three questions and is accountable for the answers.
- What is this identity for? A purpose statement in one sentence. If nobody can produce it, the identity is a candidate for decommissioning, not just for review.
- What would break if it stopped working? The dependent systems, pipelines and customers. This turns rotation from a gamble into a change.
- When should it stop existing? An end date, a project milestone, or an explicit “indefinite, reviewed quarterly”.
An identity with a name attached but none of those answers has a contact, not an owner.
Attribution: finding owners without asking everyone
The good news is that most environments contain more ownership evidence than people realize; it is just scattered. Look for signals and rank them:
| Signal | Where it lives | Strength |
|---|---|---|
| Creator or last modifier | Cloud audit logs, infrastructure-as-code commit history | Lead |
| Deployment pipeline | The CI/CD job that provisions or uses the credential | Strong |
| Code ownership | Repository CODEOWNERS files, module owners | Strong |
| Tags and naming conventions | team=, owner=, ticket prefixes |
Medium, often stale |
| Cost allocation | Billing tags, project hierarchy | Medium |
| Who responds | Past incident tickets that mention the identity | Strong |
| Usage pattern | Which services and runners authenticate with it | Corroborating |
No single signal is authoritative. A CODEOWNERS entry pointing at a disbanded team is evidence of past ownership. The combination — the pipeline that uses it lives in a repository owned by team X, tagged with team X’s cost center, last modified by a current member of team X — is a suggestion a human can confirm in seconds.
That confirmation step matters. An attributed owner is a hypothesis. An attested owner is a control.
Making ownership stick
Ownership decays. Teams reorganize, people leave, services are handed over. A few practices keep it real:
- Attest on a cadence, not once. Quarterly for production identities, at least annually for everything else. A missed attestation is itself a finding.
- Tie attestation to offboarding. When an owner leaves, their identities should show up in someone’s queue the same day — not at the next audit.
- Record the evidence, not just the name. Why do we believe team X owns this? Keep the signals alongside the attestation so the next reviewer can check the reasoning.
- Make “unowned” a visible state. Hiding orphans in a default “platform team” bucket feels tidy and destroys the signal.
- Treat agents the same way. An AI agent that can open pull requests or move money needs an owner who will answer for its actions before it takes them, not after.
Where this leaves the inventory
An inventory without ownership is a list. An inventory with ownership is a program: every finding routes somewhere, every remediation has a human who can judge it, and every decommission has someone willing to sign. That is why ownership and lifecycle sit in the first phase of the Trustivan platform alongside discovery and classification — and why credential findings and effective access, which depend on them, come after them. All of it is available today.
If your program has stalled on “who owns this?”, the fix is not a better scanner. It is making ownership a first-class object with evidence, an attestation and an end date. Everything else gets easier once it exists.