When the Employee Leaves but the Agent Stays
AI agents built by departing employees keep running long after their creator's Okta account is disabled. They still have access. Nobody owns them. Here is what to do about it.
The orphaned agent problem
Your offboarding process catches the obvious things. Okta account disabled. Laptop returned. Slack deactivated. The employee is gone.
What it does not catch: the three AI agents they built over the past year. One reads the CRM and sends weekly pipeline summaries. One monitors the GitHub repo and posts alerts to Slack. One runs nightly against the billing data and generates reports. All three are still running on Monday morning. All three still have access. None of them appear anywhere on the offboarding checklist.
This is the orphaned agent problem. It is new, it is growing, and almost no standard offboarding process accounts for it.
Why standard offboarding misses it
Traditional offboarding was designed for a world where access meant accounts. Disable the SSO account, deprovision the federated apps, revoke the VPN. Done.
AI agents break that model in two ways.
First, agents typically authenticate with API keys or OAuth tokens rather than SSO. When you disable an employee's SSO account, those credentials are not automatically revoked. The agent keeps calling APIs with the same token it has always used, under the same permissions, with no indication in any log that its owner no longer works there.
Second, agents are not in your identity provider. There is no user record to disable, no group membership to remove, no SCIM event to trigger. The agent simply does not exist in the systems that handle offboarding.
The result: an agent built by a departed employee is functionally indistinguishable from one built by a current employee, right up until something goes wrong.
Three scenarios that play out differently
The sales ops manager leaves. She built an agent that reads HubSpot deals every Monday and sends a summary to a Slack channel. Nobody knows she built it. It keeps running. Six months later, the channel gets a message with deal names and amounts. The new sales ops manager has no idea where it is coming from or how to stop it.
The risk here is not immediate but it compounds. An unowned agent with live business data access, no audit owner, and no one who knows how to modify or stop it represents ongoing exposure that quietly grows.
A developer built an agent using their own Google OAuth token to access Google Drive. Their Google account is disabled on their last day. The agent's token is invalidated. Every downstream process that depended on the agent fails silently or starts throwing errors. IT gets involved, nobody knows what the agent was doing or how it was set up, and recovery takes days.
This scenario is actually the better outcome. At least the access is gone. The problem is the operational disruption, not the security exposure.
An engineer built an agent and provisioned it with a service account they created specifically for it. The service account is not tied to the employee's SSO identity. When the engineer leaves, their SSO account is disabled. The service account persists. The agent persists. Six months later, the engineer is discovered to still have access to production systems through the service account, which was never in scope for the offboarding ticket.
This is the worst outcome. Persistent access, no audit trail of who owns it, and potentially a security incident waiting to happen.
What to do at departure
When an employee leaves, the question for AI agents is not just "disable" versus "keep running." It depends on whether the agent is still useful to the business.
The evaluate step is often skipped under time pressure. The instinct is to suspend everything immediately. That is the safe default for security, but it can break operational workflows without warning. A brief review window of 24 to 48 hours before suspension gives the team time to identify critical agents that need reassignment rather than removal.
The ownership model that prevents the problem
The scenarios above share a root cause: agents were created without a formal ownership record that the offboarding process can act on.
The fix is to treat agent ownership the same way you treat human role assignments. When an agent is registered, it gets an owner. That owner is a named employee in your identity system, not a team or a department. When that employee is flagged for offboarding, every agent they own is flagged alongside them.
The billing-reporter agent has a risk score of 74 because it has read access to Stripe. That is the one that needs immediate attention. The pipeline summarizer and repo watchdog can probably be reassigned with minimal review. Without a registry that surfaces this automatically, all three are invisible to the offboarding process.
For each flagged agent, the decision comes down to three options:
The agent is still useful. A new owner takes responsibility, reviews the current access bindings, and confirms the scope is still appropriate for the work the agent does.
The agent may be useful but needs more review than time allows right now. Suspend it immediately to stop access, then evaluate within a defined window (48 hours is reasonable).
The agent was personal to the departing employee, or nobody is willing to own it going forward. Revoke access, document the decision, and retire it.
The compliance angle
SOC 2 CC6.3 requires that access is removed when no longer needed. An agent whose owner has departed and whose access has not been reviewed is, by definition, access that may no longer be needed. If an auditor asks "how do you ensure access is removed when an employee leaves" and the answer does not cover AI agents, that is a gap in the control.
The EU AI Act adds a layer on top. Article 14 requires that high-risk AI systems include mechanisms that allow humans to oversee and intervene. An unowned, undiscovered agent running against production data has no human in the loop at all. That is an accountability gap, not just a security one.
The practical requirement is straightforward: every AI agent in your environment needs a named owner in your identity system. When that owner is offboarded, the agent is automatically flagged for review. The review decision, whatever it is, gets logged with a timestamp and the name of the reviewer. That is what a defensible control looks like.
What makes this hard is the discovery step. You can only flag agents whose owner is departing if you know which agents exist. A registry that captures agent creation from the start is what makes the offboarding step tractable. Without it, you are always doing archaeology: searching for agents after the fact, with no authoritative record of what was built.