Who should own revocation when an employee leaves and AI tools still have access?

IAM and security operations should treat AI-connected permissions like any other lifecycle-managed entitlement. If an extension, agent, or MCP server can still reach company data after offboarding, it should be revoked through the same process used for other non-human identities and privileged access paths.

Why This Matters for Security Teams

Offboarding is not complete when a person’s badge is deactivated if AI-connected access still exists in extensions, agents, API integrations, or MCP servers. Those paths can continue to read data, call tools, and trigger workflows long after the employee has left. The ownership problem is therefore not just an HR or IAM issue. It is a lifecycle control problem for non-human identities and privileged access paths, as described in the OWASP Non-Human Identity Top 10 and in NHIMG’s Ultimate Guide to NHIs.

The practical risk is that revocation gets split across teams: HR closes the employee record, IAM removes interactive access, and the AI platform team assumes the integration owner will clean up the rest. That gap is where stale grants survive. The more dangerous the tool, the more likely its access was embedded in service tokens, delegated OAuth consent, or shared workspace configuration that no one thinks to review during exit. In practice, many security teams encounter these residual paths only after a former employee’s automation has already touched sensitive data or production systems, rather than through intentional lifecycle review.

How It Works in Practice

Best practice is to assign primary revocation ownership to IAM or identity operations, with execution support from the system owner for the AI tool or integration. That creates one accountable function for removing the entitlement, while still requiring technical knowledge from the platform team to invalidate the right tokens, API keys, delegated grants, and service accounts. For AI-connected workloads, revocation should be treated like privileged access termination, not a normal user disablement.

A workable process usually includes:

• Identifying every AI-connected entitlement tied to the employee, including browser extensions, copilots, agents, shared prompts, and MCP endpoints.
• Revoking human access and non-human access separately, since one may not remove the other.
• Invalidating short-lived and long-lived secrets, not just passwords.
• Checking whether any agent or workflow was authorized on behalf of the employee through delegated consent.
• Recording the owner of the underlying system so reactivation cannot happen through forgotten admin paths.

This is where identity proof and runtime context matter. Controls aligned to NIST SP 800-53 Rev. 5 Security and Privacy Controls support revocation discipline, but AI systems add extra complexity because access may be expressed through workload credentials rather than a named user account. NHIMG’s analysis of LLMjacking shows why exposed or stale credentials are especially valuable to attackers. When an employee exits, the goal is to eliminate every path the agent can still use to authenticate, authorize, or inherit trust.

These controls tend to break down when the AI tool is owned by one team, the data source by another, and the secret store by a third because no single party has end-to-end visibility into all active grants.

Common Variations and Edge Cases

Tighter revocation often increases coordination overhead, requiring organisations to balance fast offboarding against the risk of breaking legitimate automations that the business still needs. That tradeoff is real, especially where agents share service accounts or where one employee’s workflow was reused by a team.

Current guidance suggests handling these cases with explicit ownership rules rather than ad hoc cleanup. If the employee is the business approver but not the technical owner, IAM still owns the revocation ticket while the application or platform owner confirms which integrations must be preserved, reissued, or transferred. If the access is embedded in a shared AI workspace, revocation may need to be followed by reassignment of the workspace owner and regeneration of secrets so the departing employee cannot retain indirect control.

There is no universal standard for this yet, but the direction is clear: revoke first, then restore only what has an approved successor. That approach reduces the chance that an orphaned agent continues to operate under legacy consent. NHIMG’s State of Secrets in AppSec reinforces why this matters, since leaked or mishandled secrets can remain active far longer than teams expect. In environments with shared admin accounts, unmanaged SaaS automations, or loosely governed MCP connections, ownership must be explicit before the employee leaves, or revocation will always be incomplete.

Related resources from NHI Mgmt Group

• When is it crucial to implement least-privilege access for AI agents?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?