TL;DR: The hard part of non-human identity isn't finding the accounts, it's answering who's responsible for each one in a way that's still true a year from now. This post covers why ownership collapses at turnover, the three ownership models and what each one buys you, and how to keep every NHI attached to someone who can answer for it.
- The question that stalls every NHI program: not "what service accounts do we have," but "who owns this one, and is that still true?"
- "Whoever created it" always fails. Creators change teams, leave, or forget. The identity outlives the answer.
- The turnover test: if one resignation orphans twenty accounts, you don't have an ownership model, you have a list of names.
- The workable pattern: assign to a team or role, backed by a named individual, so offboarding reassigns instead of orphans.
- Ownership is the control that unlocks every other control: revocation, rotation, incident response, and offboarding all need someone to call.
An engineer resigns on a Friday. Her access gets cut the same day, cleanly, because offboarding humans is a solved problem. What doesn't get cut: the twenty service accounts she created over four years, the API keys attached to them, and the automation still running under credentials nobody else fully understands. By Monday, your environment contains twenty identities whose only documentation just left the building.
This is the question security teams raise more than almost any other when the conversation turns to non-human identity, and it's rarely phrased as a discovery problem. It's phrased as an accountability problem: how do you know who the owner of a service account is? One team put the stakes plainly: they refuse to assign NHIs to individuals at all, because if the owner of twenty service accounts leaves tomorrow, twenty identities go orphaned at once.
They're responding to a real failure mode. The question is whether removing humans from the model entirely is the right fix.
Why does service account ownership collapse the moment someone leaves?#
Because most organizations never actually assigned ownership. They recorded a creator.
The difference matters. A creator is a historical fact: this person minted the credential in 2022. An owner is a living commitment: this person can tell you what the account does, what breaks if you disable it, and whether it still needs the access it has. Creators go stale the moment someone changes teams. The identity keeps running either way, which is exactly the problem. A service account doesn't resign, doesn't get offboarded, and never shows up in an exit checklist unless something explicitly links it to the human walking out the door.
The scale makes this worse every year. Non-human identities already outnumber humans in most enterprises by an order of magnitude, and the agentic wave is accelerating the gap. As we covered in You Can't Govern the AI Agents You Can't Find, discovery without ownership is just a longer spreadsheet. An identity with no owner is an identity nobody can confidently revoke, because nobody knows what revoking it breaks.
Human owner, team, or department: what does each model actually buy you?#
There are three models in common use, and they fail in different ways.
Individual ownership gives you a real person who knows the account. It's the most accurate model on day one and the most fragile on day 400. Every departure becomes an orphaning event, and reassignment depends on the leaver's manager knowing the accounts exist, which they usually don't.
Department ownership survives any individual departure, which is why the team above chose it. The cost is diffusion: when everyone in a thirty-person org owns an account, nobody does. "IT owns it" answers the audit question and no other question. When the account misbehaves at 2 a.m., a department doesn't pick up the phone.
Team-or-role ownership backed by a named individual is the model that holds. The role carries the accountability (platform team owns the deploy credentials), and a named person carries the knowledge. When that person leaves, ownership doesn't evaporate, it reverts to the role, and your joiner-mover-leaver process triggers reassignment the same way it triggers everything else about a departure. The leaver event becomes the thing that keeps the model accurate, instead of the thing that breaks it.
One refinement worth stealing from the teams that do this well: make ownership transfer a blocking step in offboarding. A departure doesn't close until every identity attached to that person has a new named owner. It converts ownership from a spreadsheet you update when you remember to a control that maintains itself.
Where do you draw the line between a service account and everything else?#
Part of why ownership programs stall is that "service account" gets used for half a dozen different things. A long-lived account with a static credential, an assumable cloud role, a workload identity, an OAuth app, an API key, an AI agent: these have different lifespans, different blast radii, and different natural owners. A static credential wants an owner who rotates it, or better, an application that never holds it at all. An assumable role wants an owner who reviews what can assume it. An agent, as we've argued before, wants an owner who answers for what it's permitted to do.
You don't need the taxonomy to be perfect. You need every entry in the inventory to have two fields filled in honestly: what kind of thing is this, and who answers for it.
How does C1.ai keep every NHI owned?#
C1.ai discovers every identity in your environment, human and non-human, and makes ownership a first-class attribute rather than a wiki page. Each service account, key, and agent links to an accountable owner, ownership reassignment plugs into the same lifecycle automation that handles human departures, and when someone leaves, their identities surface for transfer instead of quietly orphaning. The question "who owns this?" gets an answer from the system.
See how C1.ai keeps every non-human identity owned and accounted for.
