An employee leaves on Friday. HR closes the departure ticket. IT disables the user account, collects the laptop, removes the SaaS seat, and archives the mailbox. By Monday, everyone believes the company has finished offboarding.

But a workflow the employee built six months earlier is still running. It reviews new CRM records, enriches company names through a third-party API, sends follow-up emails from a shared inbox, exports customer data to a spreadsheet, and triggers a Slack approval sequence when a deal crosses a threshold. The employee cannot log in anymore, yet the agent can still act through OAuth grants, API keys, service accounts, shared automations, and connectors approved when the employee was still trusted.

This is the offboarding gap organizations miss. Employee offboarding no longer ends with disabling a user account. In AI-enabled companies, authority is distributed across agents, workflows, integrations, and machine credentials. The next HR-IT failure will not look like a forgotten login. It will look like an autonomous workflow still acting for someone who left the company months ago.

Traditional offboarding was designed for a human-centered access model. The process asks predictable questions: Does the person still have an identity provider account? Do they still have a device? Are their SaaS licenses removed? Are their files transferred? This model still matters, but it is incomplete. The U.S. federal Identity Lifecycle Management Playbook describes lifecycle management as a way to maintain visibility into identities, associated accounts, credentials, entitlements, and access across creation, provisioning, and deactivation.[1] That principle becomes harder when a person has created automations that act through credentials not clearly owned by that person.

AI workflows spread authority in ways ordinary access reviews often miss. A sales operations analyst may authorize an agent to read the CRM, write to marketing tools, query a warehouse, and post to a team channel. A developer may create API keys for a prototype that quietly becomes production infrastructure. A manager may share a workflow with a team, but the underlying token remains bound to the original creator. In each case, the workflow becomes a non-human actor. OWASP defines non-human identities as applications, workloads, APIs, bots, and automated systems that authenticate and authorize access to secured resources; these identities commonly use passwords, certificates, tokens, and keys.[2]

The problem is not simply that these credentials exist. The problem is that HR events rarely trigger a workflow review. A leaver event may disable Okta, Microsoft Entra ID, Google Workspace, or a core HRIS account. It may not revoke a personal access token created inside a low-code automation tool. It may not transfer ownership of a shared agent. It may not rotate a webhook secret embedded in a customer-support workflow. Account offboarding and workflow offboarding are now different controls.

The result is the zombie agent: an automation with stale authority, unclear ownership, and continuing operational impact. Stale permissions are the first risk. Agents are often granted broad access because builders want the workflow to run without interruption. OWASP’s AI Agent Security guidance warns against over-permissioned tools and recommends least privilege, per-tool scoping, and explicit authorization for sensitive actions.[3] If those permissions survive the employee, the organization has preserved a power path without preserving accountability.

Unclear ownership is the second risk. When the creator leaves, who owns the workflow: the former employee’s manager, the business team that benefits from it, the platform administrator, or security? Ownership determines who approves actions, who receives error alerts, who validates data quality, and who answers when auditors ask why a record changed.

Continued data access is the third risk. A zombie agent may still read customer records, financial data, employee information, source code, or internal documents. OWASP’s AI Agent Security Cheat Sheet lists data exfiltration, sensitive data exposure, tool abuse, and excessive autonomy among key agent risks.[3] The offboarding issue magnifies these risks because the actor is no longer attached to an active employee with a current business need.

Unaudited actions are the fourth risk. If an agent writes to CRM records, sends emails, updates tickets, or changes data warehouse tables, the audit trail may show a generic integration account or an automation name. That may be technically accurate but operationally useless. Security teams need to know which business owner authorized the workflow, which human identity created or last approved it, and whether its actions still match a valid role.

Broken workflows are the fifth risk. Some agents fail later, when a token expires, a password rotates, or a vendor changes an API. That failure may hit revenue, support, compliance, or payroll-adjacent work. Here, the danger is silent dependency: the organization discovers too late that a business process depended on private automation.

Post-offboarding breach is the sixth and most serious risk. A former employee may not need direct access if an automation continues to act through a key they created, a webhook they understand, or a shared workflow they can still influence indirectly through external inputs. In that scenario, the breach does not begin with a login; it begins when stale workflow authority lets a departed person’s automation keep moving data, sending messages, changing records, or triggering approvals after the human relationship has ended. OWASP’s 2025 Non-Human Identities Top 10 names improper offboarding, overprivileged non-human identities, long-lived secrets, and human use of non-human identities as distinct risks.[4] Those categories map directly to the offboarding problem: credentials outlive people, and automation can blur the line between human action and machine action.

The Solution: The New Workflow-aware offboarding Approach

Workflow-aware offboarding starts with inventory. Every AI agent, low-code automation, scheduled job, webhook, API integration, and shared workflow should have a recorded owner, business purpose, data scope, systems touched, credential source, approval level, and last review date. The inventory should also show whether the workflow uses a personal token, shared mailbox, service account, managed identity, or vendor connector. This does not require a perfect enterprise map on day one. It requires treating workflows as assets, not personal productivity hacks.

The next step is lifecycle triggering. When an employee changes role or leaves, the identity event should automatically open a workflow review. The review should ask what agents the person created, owned, approved, scheduled, or credentialed; whether each workflow still has a business need; and whether its permissions match the new owner’s role. Each workflow should then be retired, transferred to an accountable owner, or reauthorized under a managed service identity. Credentials should be revoked, rotated, or rebound to approved workload identities. Long-lived personal tokens should be exceptions, not normal infrastructure.

Finally, organizations need post-change audit. After a departure or role change, agent activity should be monitored for unusual actions, failed credential attempts, unexpected exports, continued use of old grants, and workflows that suddenly stop. Alerts should route to the new business owner and security, not to the departed employee’s mailbox. The goal is not to block automation. The goal is to make automation governable. AI workflows can improve speed and consistency, but only if their authority follows the same lifecycle discipline expected of human access.

The closing lesson is blunt. HR and IT can no longer offboard only the person. They must offboard the work the person automated. The next offboarding failure will not just be a forgotten account. It will be an autonomous workflow still acting for someone who is no longer there.

References

[1] Identity Lifecycle Management Playbook. https://www.idmanagement.gov/playbooks/ilm/

[2] OWASP Non-Human Identities Top 10: Introduction. https://owasp.org/www-project-non-human-identities-top-10/2025/introduction/

[3] OWASP AI Agent Security Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

[4] OWASP Top 10 Non-Human Identities Risks – 2025. https://owasp.org/www-project-non-human-identities-top-10/2025/top-10-2025/