Almost every non-human identity problem traces back to one missing fact: who owns it? Without an owner, nobody reviews a service account's privileges, rotates an API key, answers an alert or decides when an integration should be switched off. Owners leave, teams reorganise and applications change hands, and the NHIs they created carry on running. This guide explains why ownership matters so much for NHIs and AI agents, what ownership actually means, how to assign it at scale and how to keep it accurate over time.
Key takeaways
- Ownership is the control that enables every other control: reviews, rotation, incident response and decommissioning all need a person to act.
- Define ownership clearly: a business owner accountable for why the NHI exists, and a technical owner responsible for how it is configured and maintained.
- Assign owners at creation, discover them for existing NHIs using several signals, and keep ownership current through joiner-mover-leaver events.
- Treat an NHI without a valid owner as a risk to be resolved within a set time, ending in suspension if nobody claims it.
Why ownership fails for NHIs
- Creation is decentralised: developers, platform teams, SaaS admins and business users all create NHIs, often with no record of who did.
- Creators are not owners: the engineer who created a service account may have moved on, while the application it serves continues.
- Organisational change: reorganisations and staff turnover leave NHIs attached to departed people or dissolved teams.
- Shared use: one NHI used by several applications has no single owner, so nobody feels responsible.
- Volume: NHIs vastly outnumber people, so manual ownership assignment does not scale.
The consequences appear throughout breach reports. In the Coupang signing key breach, credentials that were not revoked after an employee's offboarding led to exposure of millions of records. OWASP ranks NHI1 Improper Offboarding first in its Non-Human Identities Top 10.
What an owner is accountable for
| Role | Accountable for |
|---|---|
| Business owner | Why the NHI exists; approving its access; accepting its risk; deciding when it is no longer needed |
| Technical owner | Configuration, credentials, rotation, dependencies, responding to alerts and incidents |
| Backup owner | Covering absence and taking over when the primary owner leaves |
Ownership should be held by named individuals, backed by a team, rather than by a team alone. A team mailbox cannot approve a review.
Assigning owners at creation
- Require an owner, backup owner and purpose in every request for a new service account, API key, OAuth app, certificate or AI agent.
- Enforce it in automation: infrastructure-as-code modules and platform templates that refuse to create identities without owner tags.
- Use cloud and SaaS policy to deny creation of untagged identities where possible.
- For AI agents, record ownership in the agent registry before credentials are issued. See the Agentic AI Identity Guide.
Finding owners for existing NHIs
No single signal is reliable, so combine several and score confidence:
- Creator recorded in audit logs or object metadata.
- Tags and naming conventions that identify an application or cost centre.
- Consuming application: which workload or host uses the credential, mapped to the application's owner in the CMDB.
- Code ownership: the repository and code owners where the credential is referenced.
- Cloud account or project owner as a fallback.
- Who last changed or rotated it.
Then ask the likely owner to confirm. Where confidence is low, route to the account or application owner to reassign.
Keeping ownership current
- Leavers: when an owner leaves, automatically reassign their NHIs to the backup owner or their manager, with a deadline to confirm. See the Joiner-Mover-Leaver Guide.
- Movers: when an owner changes role, prompt them to transfer NHIs that belong to their old area.
- Reorganisations: reassign in bulk using application-to-team mappings.
- Periodic attestation: owners confirm ownership, need and privilege as part of access reviews.
Handling orphaned NHIs
- Flag NHIs whose owner is missing, departed or unconfirmed.
- Attempt automatic reassignment using the signals above.
- Notify the likely team with a deadline to claim.
- If unclaimed, reduce privilege or disable the credential, with a documented rollback path.
- If nothing breaks after a defined period, decommission it.
Disabling before deleting is essential: orphaned NHIs are sometimes quietly supporting critical processes.
Measuring ownership
- Percentage of NHIs with a valid, current owner, by type and platform.
- Percentage of privileged NHIs with a valid owner (target: 100%).
- Number of NHIs owned by departed staff, and time to reassign.
- Number of orphaned NHIs disabled or decommissioned.
See the Identity Security Metrics and KPIs Guide.
Practitioner checklist
- Define business, technical and backup owner roles for NHIs and AI agents.
- Require owners at creation and enforce it in automation and policy.
- Discover owners for existing NHIs using multiple signals, then confirm.
- Link NHI ownership to HR joiner-mover-leaver events.
- Include ownership confirmation in periodic reviews.
- Run a documented process for orphaned NHIs: reassign, restrict, disable, decommission.
- Track ownership coverage as a key metric.
Standards and references
- OWASP Non-Human Identities Top 10 (2025): NHI1 Improper Offboarding
- ISO/IEC 27001:2022 (asset ownership and access control)
- NIST Cybersecurity Framework 2.0 (Govern and Identify functions)
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Service Account Security Guide · Top 10 NHI Issues · The Ultimate Guide to Non-Human Identities
