Who is accountable when a service account or AI agent keeps access after offboarding?

Accountability should sit with the system owner and the identity governance owner, not just the team that requested the access. If a service account or AI agent keeps access after offboarding, that usually means the lifecycle trigger, downstream revocation, or ownership mapping was incomplete. The control failure is organisational, not just technical.

Why This Matters for Security Teams

When a service account or AI agent retains access after offboarding, the immediate problem is not just a missed ticket. It is an ownership and lifecycle failure that can leave active credentials, API keys, tokens, or delegated agent privileges in place long after the business need has ended. That creates exposure across cloud, code, and production systems, especially when revocation depends on humans remembering to clean up every downstream integration.

The issue is more serious for autonomous workloads because agents do not behave like static users. A retained identity can continue to authenticate, call tools, chain actions, and expand its reach if controls are not bound to the asset lifecycle. Current guidance from OWASP Agentic AI Top 10 and the NHI Lifecycle Management Guide both point to the same operational truth: offboarding must revoke the identity, not just close the request.

In practice, many security teams discover lingering access only after an audit, an incident, or a failed deprovisioning review, rather than through intentional lifecycle assurance.

How It Works in Practice

Accountability should be assigned where control actually exists: the system owner, the identity governance owner, and the workflow owner responsible for lifecycle triggers. For service accounts, that usually means the application owner must ensure the credential source, vault entry, CI/CD secret, and downstream trust relationships are revoked together. For AI agents, the owner must also account for runtime authorisation, tool access, and any workload identity that remains valid after a human operator leaves.

Best practice is evolving toward lifecycle-linked revocation, where offboarding events trigger automated checks across identity stores, secret managers, and authorization layers. That includes disabling or deleting the principal, revoking issued tokens, rotating shared secrets, removing group and role bindings, and invalidating workload credentials. Frameworks such as NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework reinforce the need to treat identity, policy, and runtime context as linked control surfaces.

• Map every service account or agent to a named business owner and a technical steward.
• Bind offboarding to a change event, not a manual cleanup task.
• Use short-lived credentials and rotate shared secrets when ownership changes.
• Verify revocation in downstream systems, not just in the primary directory.
• Log the full chain of custody so audits can show who accepted the risk and who executed remediation.

NHIMG’s Ultimate Guide to NHIs and Top 10 NHI Issues both emphasize that lifecycle gaps are a governance problem first and a tooling problem second. These controls tend to break down when identities are reused across teams because no single owner can see every dependent system.

Common Variations and Edge Cases

Tighter lifecycle controls often increase operational overhead, so organisations have to balance clean deprovisioning against release velocity and platform complexity. That tradeoff becomes visible when one service account supports many pipelines, or when an AI agent is embedded across several applications with overlapping tool permissions.

There is no universal standard for this yet, but current guidance suggests treating these identities differently from human access. Shared service accounts are especially risky because offboarding one owner does not automatically remove the business need, which can lead teams to leave credentials in place as a convenience. For AI agents, the edge case is delegation: an agent may keep a valid workload token even after the human sponsor departs, unless the runtime identity is tied to task completion or tenancy changes.

This is why NHIMG research on the AI Agents: The New Attack Surface report matters here. It shows that agent access often expands beyond intended scope, which means offboarding failures can persist unnoticed until data exposure or unauthorized system access is already underway. In the same vein, the 52 NHI Breaches Analysis underscores how often identity issues become incident issues once ownership is unclear.

The strongest pattern is to separate business ownership from technical operation, then require both to sign off on revocation completion. Where that separation does not exist, access tends to linger after offboarding because no one is clearly accountable for the final cleanup.

Related resources from NHI Mgmt Group

• What is the difference between AI agent access and ordinary service account access?
• What should teams do when an AI agent keeps access after a project ends?
• Who should be accountable for AI access revocation risk?
• Who is accountable when a shared administrative credential is misused after offboarding?