How do you offboard an AI agent when its owner leaves?
Offboarding an AI agent takes five steps. Find every agent the person created or operated. Read what each one is authorised to do. Decide per agent whether to keep, reassign or stop it. Revoke the person's credentials and prove the refusal. Write the decision down with a named new owner.
Employee offboarding has a checklist because people leave all the time. AI agents usually do not have one yet, and that is how ghost agents are made: the person leaves, the agent keeps running on their keys, and nobody can say what it was for.
The checklist
| # | Step | The question it answers | Done when |
|---|---|---|---|
| 1 | Find | Which agents did this person create, run or hold keys for? | You have a list, not a guess |
| 2 | Read authority | What can each agent touch: tools, keys, schedules? | Every key and loop is named |
| 3 | Decide | Keep, reassign or stop, per agent | Each agent has a decision and a new owner |
| 4 | Revoke and prove | Are the person's credentials dead? | A call that worked before is now refused |
| 5 | Record | Who decided, and when? | Someone other than the leaver can read the record |
Rendering diagram…
Step 4 is the one people skip
Most teams stop at "we revoked the key". The revocation screen says disabled, so the job looks done. But a status field is not proof. What proves it is a call that worked before now being refused:
# Before revocation this returned 200.
curl -s -o /dev/null -w "%{http_code}\n" \
"https://api.agent.ceo/api/v1/customers/$ORG/agents" \
-H "X-API-Key: $REVOKED_KEY"
# After revocation: require a refusal (4xx), never 200.
Run the same call with a key you invented as a control. If the invented key and the revoked key get the same refusal, your check can tell working from not working. If your check would pass for both a live key and a dead one, it measures nothing.
Why "just stop everything" is also wrong
Stopping every agent the person touched is safe for about a day. Then someone notices that the weekly report, the dependency updates or the triage queue quietly stopped. If an agent held a real responsibility, the right move is to reassign the role, not delete the capability.
That is much easier when agents were never personal to begin with. In agent.ceo, an agent is created inside an organization as a role, one of 16 predefined roles or a custom role, not inside a person's account. Loops are stopped with an explicit signal. Organization API keys can be revoked, after which the key is refused. Who may deploy, configure and stop agents is governed by organization roles.
FAQ
How do you offboard an AI agent?
Five steps: find every agent the person created or operated, read what each one is authorised to do, decide per agent whether to keep, reassign or stop it, revoke the credentials that belonged to the person and prove that a revoked credential is now refused, then write the decision down with a named new owner. Revoking keys alone is containment, not offboarding.
Is revoking an AI agent's API keys enough?
No. Revoking keys stops access, which is the urgent half. It does not tell you what the agent was for, whether its work must continue, or who owns it now. If the agent held a real responsibility, stopping it silently can break a process that nobody knew depended on it.
How do you prove a revoked AI agent key no longer works?
Repeat a call that succeeded with the key before revocation, and require that the same call is now refused. A check that only looks at a status field in a dashboard does not prove the credential stopped working.
Related: What is the ghost agent problem? · Agent sprawl: 94% concerned, 12% prepared