Non-human identity management: assigning owners to unowned service accounts, keys and agents
Discovery is not the hard part of non-human identity management. Learn how to propose, confirm and keep owners for service accounts, API keys, shared mailboxes and agents.
- An inventory of non-human identities reduces no risk until each one has a named owner.
- Propose owners from evidence, then have a person confirm. Never assign silently.
- Owners need dates: created, last used and when the credential expires.
- Put non-human identities in the same access reviews as people.
The hard part of non-human identity management is not finding service accounts, API keys and agents. It is deciding who answers for each one. An identity with no owner cannot be reviewed, rotated or retired with confidence, because nobody can say what depends on it. Ownership turns an inventory into something you can act on.
This guide is for identity, security and platform teams who can already list their non-human identities (NHIs) but are stuck on the long tail with no owner. It covers which identities need one, how to propose and confirm owners, what an owner needs to see, and how NHIs join your access reviews.
Why unowned non-human identities stay risky after discovery
Discovery gives you a list. It does not tell you which entries are still needed, who should approve a change to them, or who to call when one breaks.
- Nobody can say what it is for
- Nobody approves its rotation or removal
- Reviews skip it or rubber-stamp it
- A named person answers for it
- Its credential has dates someone watches
- It is certified in the same review as people
Unowned identities also tend to accumulate. A service account outlives the project it was created for, a key outlives the engineer who made it, and an agent built by one team quietly gains users across the company. Each is an orphaned account in all but name.
Which non-human identities need an owner?
Every one that holds access. In practice that means four broad groups.
Service accounts and application identities
Accounts your systems sign in as, plus the application registrations and service principals your directory creates. They are often created for one job and kept long after the job changed.
API keys and tokens
Keys and personal access tokens have no login and no session. They work until someone revokes them, so an unowned key is one nobody is watching.
Shared mailboxes and similar shared identities
A shared mailbox rarely feels like an identity until its password sits in several people's notes. It needs an owner like anything else, and a shared password is not ownership.
Agents and automation identities
AI agents and automations act on your systems, sometimes on behalf of many users. They are the newest and fastest-growing group, which makes clear ownership more important, not less. For what to govern once an agent has access, see governing AI agent actions after access is approved.
A practical ownership workflow
Treat ownership as a small workflow with four steps, not a one-off spreadsheet exercise.
- 1ProposeSuggest an owner from evidence: creator, team, usage.
- 2ConfirmA person accepts, or redirects it to the right owner.
- 3RecordOwner, purpose and credential dates on the record.
- 4ReviewThe owner certifies its access each cycle.
Propose owners from evidence
Good starting signals for a proposed owner:
- Who created it, if that person is still at the company.
- Which team uses it, from sign-in or activity data.
- Which system it runs in, and who owns that system.
- What it is for, from its name, description or the integration it came from.
If the creator has left, propose their manager or the owner of the system the identity runs in, rather than leaving it blank.
Have a person confirm
Record more than a name
A name alone does not help the next reviewer. Record what the identity is, what it can reach, why it exists, which system it runs in, and the team that depends on it.
Credentials need dates as well as owners
An owner can only act on what they can see. For each credential, show:
- when it was created, and by whom
- when it was last used, so unused identities stand out
- when it expires, so a lapse is a planned event rather than an outage
- for federated credentials, which issuer and subject the trust covers
Identities nobody has used in months are the easiest wins. Removing a stale key shrinks what you have to defend, usually without breaking anything. Check the last-used date and confirm with the owner first.
Fold non-human identities into access reviews
NHIs should sit in the same access review campaigns as people, labelled as what they are. A service account should appear as a service account, not an unknown user, and its owner should certify it.
Two rules keep this workable:
- The owner reviews it, not whoever happens to own the application.
- Unowned identities get their own control group. Track "identities with no owner" as a number with a severity, and work it down, rather than letting them drop out of reviews.
Questions to ask vendors about NHI ownership
Several identity vendors now offer suggested owners for unowned NHIs or broader NHI discovery. When you evaluate any of them, ask to see:
| Ask to see | Why it matters |
|---|---|
| An owner proposal and its evidence | You need to know why that person was suggested. |
| What happens before confirmation | Silent assignment creates owners who never agreed. |
| An identity whose creator has left | This is the most common unowned case. |
| Created, last-used and expiry dates | Owners act on dates, not just names. |
| An NHI inside a review campaign | Discovery without review leaves risk in place. |
| The unowned count over time | The trend shows whether ownership is sticking. |
How Ploy handles non-human identity ownership
Ploy's non-human identity management keeps service accounts, keys, shared mailboxes and agents in one inventory next to your people. Each machine shows who created it, when its credential expires and when it was last used. When an identity has no owner or a credential lapses, Luna, Ploy's identity agent, proposes the fix and waits for a person to confirm it. Unowned agents, expired credentials and dormant machines start as control segments, and NHIs join the same access reviews as your people.
To see an unowned service account go from discovery to a confirmed owner and a review, book a demo.
Frequently asked questions
What is non-human identity management?
It is the practice of inventorying, owning, reviewing and retiring identities that are not people: service accounts, application identities, API keys, tokens, shared mailboxes and AI agents. Ownership is the step that makes the rest possible.
Who should own a service account when its creator has left?
Usually the owner of the system it runs in, or the manager of the team that uses it. Propose that person, ask them to confirm, and record the reason. If nobody will take it, treat it as a candidate for removal and check its last-used date.
Should AI suggest owners for non-human identities?
Suggestions save time, as long as a person confirms each one. An owner who did not agree to the role is unlikely to act on reviews or expiry warnings.
How often should non-human identities be reviewed?
On the same cadence as the human access they resemble. Privileged service accounts and long-lived keys deserve the same scrutiny as admin users.