Agent offboarding is the leaver stage for the things that keep working after a person has gone. An AI agent connected to the ticketing system, an integration authorized with someone's workspace account, a personal access token in a deployment pipeline: each of these authenticates without the person, and none of them has a leaving date.
Ordinary offboarding answers the question "what did this person hold". Agent offboarding answers the harder one: "what did this person create that still runs". The second list is longer, it is invisible from the identity provider, and nothing in the HR system points at it.
one person leaves. two lists.
WHAT THEY HELD WHAT THEY CREATED
(the checklist covers this) (nothing points at this)
-------------------------- -------------------------
directory account personal access tokens
app accounts API keys in a config file
group memberships OAuth grants they consented to
sessions and refresh tokens automations running as them
service accounts they made
AI agents wired to their session
webhooks pointing at their laptop
the test: after the leaver's last day, which of the right-hand column
still runs, and who owns it now?Why does offboarding miss them?
Because every trigger and every checklist is built around accounts, and these are not accounts.
The trigger is a person's status
HR marks a termination and the leaver workflow removes whatever the directory says that person held. Nothing in the directory records that the same person authorized four integrations and issued two tokens, so nothing in the run goes looking for them. The directory is an accurate list of what was granted through it, and that is a different list from what the person created.
The checklist was written from memory
A checklist names the applications someone remembered, which are the applications people log into. Tokens, grants and agents have no login, so they never came up in the conversation that produced the list. Checklists also age in one direction only: a new application gets added, and a new kind of credential does not.
The artefacts sit in other people's consoles
A token lives in the code host's developer settings, a grant in the workspace admin console, an agent in whatever tool it was configured in. None of those is where offboarding happens, and several are administered by a team other than the one running the leaver process. Finding them takes an inventory per system rather than one query against the directory.
Nobody is asked to claim them
An automation with no owner keeps working, and work that keeps working generates no ticket. The only signal such an identity produces is the one it produces when it finally breaks, which tends to be months later and gets attributed to something else.
What has to be revoked, reassigned or left alone?
Three outcomes, and deciding which is the whole job. The default matters: anything nobody will claim is revoked.
| What the leaver created | Where it lives | Default outcome |
|---|---|---|
| Personal access tokens | The code host, the identity provider, each SaaS developer setting | Revoke. A personal token is personal, whatever it was automating |
| OAuth grants they approved | The workspace admin console, each application | Revoke, unless the integration is a company purchase, then reissue under a service identity |
| Automations running as them | The integration platforms, the scheduler, cron on a server | Reassign to a named owner and re-authenticate, or revoke |
| Service accounts they created | The directory, cloud consoles, databases | Reassign, with the secret rotated, because they knew it |
| AI agents they configured | Coding tools, chat platforms, internal deployments | Reassign with the scope re-approved, or revoke |
| Webhooks and callbacks | Each application's integration settings | Revoke, and expect one thing to break loudly rather than quietly |
Why revoke is the default
An unclaimed identity is a liability with no upside. The cost of a wrong revocation is a broken job that somebody notices within a day. The cost of a wrong reassignment is an identity that looks governed and is not. Making revoke the default also moves the burden onto whoever wants the thing kept, and the person who speaks up becomes its owner by asking.
The rotation argument
The rotation question is the one practitioners argue about, and the argument is worth reading in full. One side says a key that a departing employee once knew is no longer a key anyone can reason about:
If a person previously had access to the key and knowledge of the key gives you control over that automated workflow, is that key (and by extension that workflow) still worth trusting?
The answer that removes the argument is to stop issuing credentials a person can hold: short-lived, narrowly scoped, issued on demand. Then a departure changes nothing, because there is nothing durable to have taken.
What does an agent offboarding run look like?
The same run as the person's, with a second list in it.
1The termination fires the run
The HR event starts the leaver workflow, which closes accounts and revokes active sessions as it already does. Session revocation matters more than it appears to. An account can be disabled while an open session or a refresh token keeps working. That is why the platform guidance for revoking access in an emergency treats revoking tokens and sessions as steps of their own, rather than as consequences of disabling the user.
2The run queries for what the person created
Every connected system is asked for artefacts attributed to that person: tokens they issued, grants they approved, service accounts and agents naming them as creator or owner. This step does not exist in a conventional offboarding process. It is also the step that forces the run to reach applications directly, because the directory has no record of what was created inside them.
3Each artefact gets a decision
The default is revoke. Anything the business needs is reassigned to a named owner, with the credential rotated and the scope re-approved by whoever now owns it. A decision recorded without a name attached is not a decision, because the next person to read the record cannot tell whether the identity was kept on purpose.
4Revocations execute where the credential was issued
An OAuth grant is withdrawn at the authorization server, over the token revocation endpoint where one is offered and in the admin console where it is not. Deleting a stored secret without withdrawing the grant is the common half-finished version, and it leaves the integration able to mint a fresh token the next time it runs.
5Reassignments carry a re-justification date
A reassignment with no date attached is a way of making the problem quieter. The new owner receives a date on which the identity is re-justified or removed, which turns a permanent transfer into a decision that expires.
6The record covers both halves
The evidence lists what was closed and what was reassigned to whom. An auditor sampling that leaver sees the accounts and the artefacts in one place. That is the difference between a clean record and a record that is clean about half of the question.
Offboarding in Iden runs against both lists. The workflow closes the person's accounts and, in the same run, flags every token, OAuth grant, service account and agent that person created, with the owner to reassign to or the revocation to execute. The Workflows screen shows the run and what it touched, so the record covers what the leaver made as well as what they held. The feature behind it is Offboarding you can prove, not just tick.
Neun Workflows in drei Gruppen. Entscheidend ist die Spalte mit den Applikationen: Das Basis-Onboarding betrifft 32, ein Standortwechsel nur 3.
How is it prevented rather than cleaned up?
By making creation the moment ownership is recorded, which is the only point at which anyone knows what the thing is for.
Give every non-human identity an owner at birth
A token, grant, service account or agent created through a path that records who owns it and what it is for can be found on the day its owner leaves. One created in a developer settings page cannot.
Prefer short-lived credentials
An identity that mints its own credential on demand has no secret to inherit. This is the same reason infrastructure moved to workload identity, and it applies to a company's own automations.
Ask what a credential can do before an agent holds it
A widely read incident where an agent destroyed a production database drew this response, and it is the right question for every credential a person hands to something that acts on its own:
Why don't you know what your credentials have permissions to do? Why are you storing credentials in files? Why don't you have network level isolation between environments?
Review the non-human population on its own cadence
People are reviewed because a framework says so. Non-human identities need the same treatment by a different route: to their owner, with what the identity reached recently beside it. The useful question is not whether the access is plausible but whether it is still being used.
Does any framework require this?
Not by name, and that is changing.
What the criteria already cover
SOC 2 CC6.2 and ISO 27001 A.5.18 require access to be removed when it is no longer required, and neither distinguishes between a person's account and the token that person issued. PCI DSS is more direct, requiring credentials used by applications and systems to be changed when somebody with knowledge of them leaves. That is the rotation argument written into a standard rather than debated on a forum. The OWASP Non-Human Identities Top 10 then ranks improper offboarding first, and that is the clearest published statement that this is the failure mode to expect.
What auditors are actually sampling
Sampling has moved faster than the wording of the frameworks. Service accounts now turn up in samples routinely, usually with a request for the owner and the date of the last review. An account with neither is a finding whatever the control happens to be called. Agents are the next population to arrive in those samples. The ones that pass will be the ones created through a path that recorded an owner, because nothing else produces the answer on the day it is asked for.