How to offboard AI agents when an employee leaves

4 min read · Published 17 October 2026

Companies have a routine for people who leave. Laptops come back, accounts close. Agents that person built usually have no routine at all. Here is one.

Short answer

Treat every agent as an account that has an owner. When the owner leaves, list their agents, decide to transfer or retire each one, set the ones you retire to inactive, revoke their tokens and keys, and check that nothing still works. SCIM covers the inactive part. The rest is process.

Why this matters

The OWASP Non-Human Identities Top 10 for 2025 puts Improper Offboarding at number one (NHI1:2025). It opens by describing it as the inadequate deactivation or removal of non-human identities, such as service accounts and access keys that are no longer needed, which attackers can use to reach sensitive systems and data. An agent that outlives its owner fits that description exactly.

Two other items on the same list make it worse: Overprivileged NHI (NHI5) and Long-Lived Secrets (NHI7). An agent with broad access and a token that never expires is the worst version of an orphan.

The checklist

1. Find every agent the person owned

You cannot offboard what you cannot list. If you keep an agent inventory with an owner field, this is a single query. If you do not, ask the person's manager and their team, and check which agent and API credentials were created from their account.

2. Decide: transfer or retire

For each agent, pick one. Transfer it to a named new owner, or retire it. A bot that answers IT questions might be worth keeping. An experiment from last spring probably is not. Do not leave "no owner" as an outcome.

3. Deactivate in the directory

For agents you retire, set the record to inactive. In SCIM terms that is the active attribute. RFC 7643 describes false as typically meaning the account is suspended, and says the definitive meaning is up to the service. Okta's docs say a deprovisioned user in a SCIM app is updated with active=false, and that is a good model for agents too.

4. Revoke credentials separately

Do not trust the flag to kill access. Revoke OAuth tokens (RFC 7009 describes how), rotate or delete API keys, and remove certificates. We explain why in SCIM vs OAuth for AI agents.

5. Check downstream apps

Changes in the directory reach apps on a schedule. Microsoft's Entra SCIM tutorial says its sync runs about every 40 minutes after the initial cycle. Find the real interval for your own identity provider, and for anything urgent, such as a compromised agent, be ready to act in the app directly. The demo on the home page shows the ideal case, where one request reaches every app at once.

6. Soft-delete first, keep the record

Microsoft's tutorial describes soft deletion as active=false and says the user object should still be returned by the app whether or not it is active. Use the same idea. Keep the agent's record for a set period, so an auditor can ask who created it, who owned it and when it was switched off.

7. Verify

Try to use the agent. Call an API with its old token. Look at the logs for anything running under its name since the cutoff. A shutdown you have not tested is a guess.

Suspend, quarantine or archive?

"Switched off" is not one thing. Oracle's governance draft spells out three different meanings, and they are a useful way to think even before the standard exists.

Suspended. A temporary pause by an administrator, reversible. Outstanding tokens should be revoked or suspended. Use it for an agent whose owner left but whose job still matters until a new owner is found.
Quarantined. Frozen because of a security concern. All access is blocked, and the record and evidence stay exactly as they were. Use it when an agent may be compromised.
Archived. The end. Authority is permanently withdrawn and the record is kept for audit. The draft does not allow restoring an archived agent. If you need the function again, create a new agent.

The base draft only has the active flag. The states above come from the optional extension, described under lifecycleState. A validity window (validFrom and validTo) can also end a pilot agent automatically, so a forgotten test does not outlive its purpose.

A sample timeline

This is an example policy, not a standard. Adjust it to your own risk level.

When	Action
Day of notice	List the agents the person owns. Mark each as transfer or retire.
Last day	Deactivate retired agents. Revoke their tokens and keys. Reassign owners for the rest.
Day 1	Verify nothing still runs under the old identities.
Day 30	Review the deactivated records. Delete what you no longer need to keep.

What the standard will not do for you

The IETF draft gives an agent an owners field and an active flag. It does not say what should happen to the agent when its owner is removed. The details are here. That rule is yours to write. The simplest one that works: an agent whose owners are all inactive gets flagged within a day, and someone has to claim it or switch it off.

You can see why this matters in the use cases on the home page, in particular offboarding and the kill switch.

Sources

Own the name for this category.

agentscim.com is for sale. If you build identity, security or agent tooling, write to me. Serious offers get a reply within 24 hours.

Make an offer

Keep reading

This is an independent page. It is not affiliated with the IETF, Okta or Microsoft. Standards and drafts change, so check the linked sources for the current state.