Who should own orphaned service accounts and AI agent identities?

Ownership should sit with a named business or technical custodian who can approve use, monitor activity, and trigger offboarding when the identity is no longer needed. Without accountable ownership, the identity remains live by default and becomes a governance gap rather than an operational asset.

Why This Matters for Security Teams

Orphaned service accounts and AI agent identities should not be treated as leftover admin clutter. They are active trust objects with the power to authenticate, call APIs, move data, and trigger workflows. When no named owner exists, no one is accountable for approval, monitoring, rotation, or shutdown, so the identity remains live by default.

This risk is sharper for agents because their access is not always tied to a human schedule or a static business role. The latest guidance in the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward explicit accountability for autonomous systems, not implied ownership through infrastructure teams. NHIMG research on AI agents as a new attack surface shows why this matters: 80% of organisations report agents have already acted beyond their intended scope.

In practice, many security teams encounter orphaned identities only after access reviews, incident response, or a post-breach audit reveals the account was still active long after the business process had moved on.

How It Works in Practice

Ownership should be assigned to the function that can actually answer three questions: why does the identity exist, who approves its continued use, and who can deactivate it immediately. For service accounts, that is often the application owner or platform team with clear operational custody. For AI agents, the owner is usually the product, engineering, or automation team that defined the agent’s task and risk tolerance, with security acting as control adviser rather than custodian.

Good practice is to bind ownership to a named person and a named team, then record that in the identity inventory and change management workflow. That owner should approve onboarding, periodic review, secret rotation, scope changes, and offboarding. Where possible, link the identity to workload identity primitives such as SPIFFE-style identity or signed OIDC assertions so the system can prove what it is, not just what secret it holds. NIST’s AI guidance and the CSA MAESTRO agentic AI threat modeling framework both support this shift toward explicit lifecycle governance.

• Assign a business owner and a technical custodian for every non-human identity.
• Require an approval path for access expansion, not just initial creation.
• Track last-used date, purpose, secret age, and downstream systems touched.
• Set an offboarding trigger for project closure, tool retirement, or agent decommissioning.
• Escalate orphan status quickly when the listed owner no longer exists.

NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities frames this as a lifecycle problem, not a one-time provisioning task. These controls tend to break down in shared-platform environments where dozens of teams reuse the same automation account because no single owner has authority to retire it.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance faster delivery against stronger accountability. That tradeoff becomes visible in platform engineering, managed service integrations, and multi-agent orchestration where one identity may serve several workflows. Current guidance suggests avoiding “team owns everything” assignments because they create diffusion of responsibility, but there is no universal standard for this yet.

When ownership is unclear, the least risky fallback is to assign the identity to the system of record owner and a secondary technical steward, then enforce a review deadline. For AI agents, that owner should also be responsible for approving tool access, data access, and any change in autonomy level. This is especially important when an agent can chain tools or access sensitive data, as NHIMG research on the OWASP NHI Top 10 and the AI LLM hijack breach shows how quickly scope can expand.

One useful rule is simple: if no one can approve, monitor, and retire the identity, it is already orphaned even if it still has credentials. That is the point where security should freeze or quarantine it pending formal ownership assignment.

Related resources from NHI Mgmt Group

• Who should own lifecycle control for service accounts and AI-enabled identities?
• What breaks when service accounts are reused across Vertex AI projects?
• Why do shared service accounts create more risk than dedicated workload identities?
• Who should own digital trust when certificates, workloads, and AI identities overlap?