Who should own offboarding when an AI agent is retired or replaced?

Why This Matters for Security Teams

Retiring an AI agent is not a paperwork exercise. The owner of the workflow, platform, or service that created the agent needs to drive offboarding because that team understands the agent’s tool chain, secret stores, delegated scopes, and downstream integrations. If HR or a generic identity queue handles it alone, revocation often stops at the user record while machine access remains live. That gap is exactly where autonomous software becomes a lingering security condition rather than a decommissioned asset. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward explicit accountability for agent lifecycle risk, not shared ambiguity. NHIMG research shows why this matters operationally: 91% of former employee tokens remain active after offboarding, according to The 2025 State of NHIs and Secrets in Cybersecurity, which is a close analogue for agent retirement failures. In practice, many security teams discover offboarding gaps only after an agent is still calling APIs long after the business thinks it has been shut down.

How It Works in Practice

The cleanest model is a named system owner with a control checklist, while security and IAM provide enforcement. That owner should initiate retirement, confirm replacement or shutdown, and verify that every associated permission is revoked in one coordinated event: delegated access, service principals, API keys, refresh tokens, vault entries, MCP connectors, queue subscriptions, and any inherited RBAC grants. For agentic workloads, static role cleanup is not enough because the agent may have been operating through dynamic, goal-driven behaviour that changed which tools it touched over time. The better pattern is intent-based authorisation at runtime, short-lived JIT credentials, and workload identity that can be invalidated at the cryptographic root rather than by manual account deletion. For design context, NHIMG’s OWASP NHI Top 10 and the NHI Lifecycle Management Guide both reinforce that lifecycle control must extend to secrets, not just identities. External implementation guidance from the CSA MAESTRO agentic AI threat modeling framework also aligns with treating agent retirement as a threat containment step, not a ticket closure. A practical offboarding sequence is usually:

• Freeze the agent’s ability to obtain new credentials or tokens.
• Revoke current secrets, certificates, and refresh tokens.
• Disable all tool connectors, webhooks, and plugin grants.
• Invalidate any standing sessions and rotate shared dependencies.
• Confirm logs, queues, and schedulers no longer trigger execution.

The point is to remove the agent’s operational path, not just its named identity. These controls tend to break down in multi-team environments where the agent spans SaaS tools, shared vaults, and independently managed control planes because no single team has a complete inventory.

Common Variations and Edge Cases

Tighter offboarding often increases coordination overhead, requiring organisations to balance speed of retirement against the risk of leaving hidden access behind. That tradeoff is especially visible when the retired agent is being replaced by a newer version, because teams may want continuity while still needing a hard cutover. Best practice is evolving, but current guidance suggests treating replacement as a fresh trust boundary: create a new workload identity, reissue only the minimum required JIT secrets, and retire the old agent only after downstream dependencies have switched. This is where autonomous systems differ from human joiner-mover-leaver processes, because the old agent may still have implicit authority through cached context, scheduled jobs, or delegated tool chains. The hardest edge cases involve shared credentials, overused NHIs, and duplicated secrets. NHIMG’s Top 10 NHI Issues highlights how overuse and duplication create hidden dependencies that survive retirement. When one agent shares a token with another application, revocation can cause unintended outages, so teams need dependency mapping before shutdown. The SailPoint report AI Agents: The New Attack Surface found that 80% of organisations already saw agents act beyond intended scope, which is a strong signal that offboarding must include a review of all tool access, not just the “retired” agent record. The practical rule is simple: if the agent can still authenticate, it is not really retired.

Related resources from NHI Mgmt Group

• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?
• When do AI agent credentials create more risk than they reduce?