SSOGEN / Learn / Offboarding AI Agents: What Happens When an Employee Leaves
Learn
Offboarding AI Agents: What Happens When an Employee Leaves
Offboarding AI agents means that when an employee leaves, every agent they owned, shared or let act for them is stopped or handed to a new owner on the same day, not left running on its old credentials.
Updated
The short answer. Offboarding AI agents belongs on the leaver checklist next to the laptop and the badge. An agent holds its own key or token, so disabling the person does not stop it.
The rule. Every agent has a named owner. When that owner leaves, each agent either gets a new owner or is suspended, and nothing keeps working in between. This page covers the agents a leaver leaves behind, not tools that automate the person’s own deprovisioning.
What happens to an AI agent when its owner leaves?
Without an owner rule, nothing happens: the agent keeps calling your applications with the access it was given. OWASP ranks this first in its Non-Human Identities Top 10 as NHI1, Improper Offboarding, and rates it easy to exploit and hard to detect.
A departure leaves four kinds of agent behind. Each needs a different step.
| Situation | What keeps working | Step |
|---|---|---|
| Orphaned | The leaver was the only owner; the agent’s key and grants still work | Hand over to a new owner, or suspend |
| Co-owned | Another owner remains; everything keeps working, which is correct | Confirm the remaining owner accepts it |
| Acting for the leaver | Tokens issued on the leaver’s behalf | Refuse new tokens; let issued ones expire |
| Known secret | A key the leaver could read but did not own | Rotate the key the same day |
Stop or hand over: how to decide for each agent
Hand an agent over when a business process depends on it and someone can answer for it. Stop it when nobody can.
Ask these questions in order for every agent on the leaver’s list.
| Question | If yes | If no |
|---|---|---|
| Does a running process depend on it? | Go to the next question | Suspend, then revoke after a waiting period |
| Will a named person accept ownership today? | Hand over and set a new review date | Suspend until someone does |
| Does its access still match the new owner’s task? | Keep the grants | Remove the difference before reactivating |
| Could the leaver read its private key? | Rotate the key | No key change needed |
Suspend first when in doubt. A suspension is reversible; a permanent revocation is not.
A same-day offboarding checklist for AI agents
NIST SP 800-53 asks for the same steps for every account, human or not: notify account managers when a user leaves (AC-2 h.2), align account processes with termination (AC-2 l), and disable accounts no longer tied to an individual (AC-2(3) b).
- List the agents. Find every agent the leaver owned, co-owned or let act for them. Include MCP clients, automations and services.
- Decide per agent. Apply the table above and record the decision.
- Stop new tokens for the person. Disable the leaver’s account so no agent can get a token on their behalf (PS-4 a and b).
- Rotate exposed keys. Replace any key the leaver could read, even on agents they did not own.
- Confirm the new owners. Each new owner reviews scopes and sets a review date (PS-5 a and c).
- Check the audit log. Look for agent activity after the leaver’s last day. Any is a finding.
The AI agent governance checklist covers the other five controls that make this work, such as scopes and review dates.
How SSOGEN offboards AI agents with their owner
SSOGEN ties every AI agent to the people who own it, so the owner’s departure reaches the agent.
- Owners are people. Each agent, MCP client, automation or service has one to five owners, never a group, and exactly one primary owner.
- Every path. When an owner is disabled, archived or deleted, including through LDAP sync or SCIM, SSOGEN applies the owner rule.
- Hand over or suspend. If another owner remains, the primary role moves to them. If none remains, the agent is suspended with the status “Suspended: its owner left. Add an owner before reactivating.”
- No reactivation without an owner. Reactivating an ownerless agent is refused with “A non-human identity needs at least one owner.”
- Delegations end with the person. Once a person is disabled, every token request on their behalf is refused. Their Account page shows the reason “Your account was disabled”.
- A short tail. Suspending stops new tokens at once, and tokens already issued stop working within 5 minutes.
- Needs attention. The Overview page links to agents with no owner, with an expiry or review date within 14 days, and unused for 30 days.
- Audit. Every lifecycle event is recorded under Monitoring, then Audit.
The same user provisioning that switches a leaver off through SCIM or LDAP sync therefore reaches their agents too. See AI agent identity and AI agent access control in SSOGEN for the full model.
Worked example: three agents, one departure
James Carter leaves Acme Corp on Friday. The directory sync disables his account at 5:00 PM, and SSOGEN applies the owner rule to each agent he is linked to.
| Agent | Before Friday | After the sync |
|---|---|---|
invoice-assistant, owners James Carter (primary) and Maria Lopez |
Active | Active; Maria Lopez is the primary owner |
nightly-recon, owner James Carter only |
Active | Suspended: its owner left |
code-helper, acting for James Carter |
Active delegation | Every new token for James refused |
On Monday, Maria Lopez agrees to own nightly-recon. An administrator adds her as owner, she reviews its scopes, and the agent is reactivated with a new review date. No agent ran unowned over the weekend.
Mistakes that leave an agent running
These four mistakes leave an agent running after its owner leaves.
- Disabling only the person. The agent’s key is separate from the person’s password and keeps working.
- Group ownership. A group cannot leave, so the agent never becomes ownerless and never gets reviewed.
- Revoking too early. Revoking a still-needed agent breaks the process; suspend it until the decision is made.
- Ignoring issued tokens. A long-lived token survives the suspension. Short token lifetimes keep this tail to minutes.
The wider lifecycle, from creation to retirement, is covered in non-human identity.
Questions people ask
What is AI agent lifecycle management?
AI agent lifecycle management covers every stage of an agent’s existence: registration with a named owner, granting scoped access, review on a fixed date, ownership changes, and retirement. Offboarding is the stage most often missed, because the agent’s credentials are separate from the person who created it and do not end when that person leaves.
Should you delete or suspend an orphaned AI agent?
Suspend it first. A suspension stops new tokens and is reversible, so a business process that depends on the agent can resume once a new owner accepts it. Revoke permanently only after a waiting period with no claim. Keep the record either way, because auditors ask about past actions, not only current ones.
How quickly should agent access end when an employee leaves?
NIST SP 800-53 PS-4 asks organizations to disable access within a period they define and to revoke the authenticators tied to the leaver. For agents, the practical target is the same day as the person. With short-lived tokens, any access already issued expires within minutes after that.
What happens to an AI agent that acts on behalf of an employee who leaves?
It loses the right to act for that person. Once the employee’s account is disabled, an agent should receive no new token on their behalf, even if the delegation has not expired. The agent itself may keep working for other people, so its owner and its other delegations need a separate check.
Where to go next
- Proof of who approved what. AI agent delegation audit explains receipts for each delegated action.
- Agents in the ERP. AI agent access to Oracle EBS applies the same rules to one application.
- More explainers. The Learn hub lists related pages.
Sources, all read 2026-11-14:
- OWASP Non-Human Identities Top 10, 2025: NHI1 Improper Offboarding (OWASP Foundation).
- NIST SP 800-53 Rev. 5, controls AC-2, AC-2(3), PS-4 and PS-5 (NIST OSCAL catalog, release 5.2.0).