AI agent offboarding: the access nobody revoked
AI agent offboarding is not the account you disabled. It is the shared workflow still running on credentials that belong to somebody who left, and it breaks the day you remove them.
Somebody leaves. IT disables the account, revokes single sign-on, collects the laptop. That part is well practiced. AI agent offboarding is the part that is not.
Then the support team's Monday workflow stops working, because it ran through a helpdesk connection that person had set up, and their credentials went with them.
Or the other version, which is worse and quieter: the workflow keeps working. It keeps working because the credential is still there, still valid, still making calls under the name of somebody who left in March.
Both failures come from the same gap. Access to SaaS was granted to a person, and then a piece of shared tooling was built on top of it, and nothing connected the two facts.
Why AI agent offboarding is harder than the account
Ordinary shared credentials at least tend to be visible. Somebody set up a service account, somebody documented it, it is in a password manager.
Agent access accumulates differently. A person connects their own account, builds something useful, shares the useful thing with their team, and the team uses the useful thing. Nobody involved thinks of it as sharing a credential, because nobody handled a credential. The person who shared it thinks of it as sharing a workflow. The team thinks of it as a tool that exists.
Three properties of that make offboarding harder than it looks.
It is invisible from the SaaS side. The vendor sees one authorization belonging to one user, which is what it is. Nothing indicates that eleven other people depend on it.
It is invisible from the team's side. People using a shared toolbox see tools. They do not see whose account is underneath, and in daily use they should not have to.
It has no owner after the fact. The person who set it up has moved on to other work, possibly other teams, possibly out of the company, which is why we are here.
Do not let the removal be quiet
The tempting design is to make removal clean: delete the member, delete their connections, delete anything pointing at them. One action, no residue.
That design breaks a team's tooling with no warning and no attributable cause. Support comes in on Monday, three tools have vanished, and the connection to a person's departure on Friday is not obvious to anybody in the room.
The opposite design is also wrong: remove the member, leave the connections. Now the credentials of somebody who has left are live, and the audit answer for calls made through them is a person who no longer works there.
So the removal is refused until the question is answered. Attempting to remove a member whose connections are still referenced by a toolbox returns a refusal listing exactly which connections are involved and what they are used by. Nothing happens until somebody decides.
The refusal is the feature. It converts a silent breakage into a decision with a name on it.
The three answers
Each referenced connection needs one of three resolutions.
Transfer it. The account is genuinely a team resource that happened to be connected by one person. Reassign ownership to the organization, a team, or another member. The tooling keeps working and the credential now belongs to somebody who is here.
Delete it. The account was personal, the tooling built on it should not survive, or the access should end with the person. The connection goes, the stored credentials go, and anything pointing at it shows as unmet rather than failing mysteriously.
Re-point what used it. Sometimes the right answer is neither: the toolbox should use a different account that already exists. Change the binding, then the connection is unreferenced and cleans up on its own.
Connections that nothing references skip all of this. They are removed with the member, credentials included, because there is no decision to make.
The credential that cannot be transferred
One category is excluded from transfer entirely, and it is worth explaining because it looks like an inconsistency.
A connection made privately, never shared, is not transferable. Not "requires approval". Not possible.
The reasoning: a credential only its owner could ever use does not become somebody else's because its owner left. Transferring it would mean handing another person an authorization made under a departed employee's identity, for an account that person never had, with the vendor still recording it as the original user's session. That is not an ownership change. It is an impersonation with a paperwork trail.
Those are deleted. If the access mattered to the team, the right recovery is for somebody who currently has that access to connect it, which takes a minute and produces a credential that belongs to a person who exists.
Delegation is a warning, not a blocker
A related case that behaves differently on purpose.
When somebody shares a toolbox for others to use, the entries in it carry the authority of whoever bound the connection, so the people using it never need access to the underlying account. That is what makes shared tooling work.
When the person who bound it leaves, those entries surface as a warning rather than a refusal.
The distinction: an unresolved connection is a credential question, and getting it wrong leaves live access belonging to a departed person. A delegated entry is a continuity question, and the fix is for somebody with access to re-bind it. Blocking the removal on it would mean holding up an offboarding for something that is not a security matter and can be fixed afterwards by whoever notices.
Warnings that should be refusals are how you get incidents. Refusals that should be warnings are how you get people working around the process, which is how you get incidents by a slower route.
The part with no cache
Everything above is about connections. There is a separate question people ask in the same breath: when does the agent actually stop?
Removal and suspension revoke every live client authorization in the same transaction as the membership change. There is no window in which the membership is gone and a token still works, and there is no cache in front of that check: the revocation is read on every call.
This is worth knowing precisely, because the rest of the access model is not the same. Changing somebody's role, or editing a restriction, propagates in about two minutes. That is fine for governance work. It is not what you want during an urgent departure, and it is not what you should reach for.
For "this person needs to stop reaching things now", the moves are removal, suspension, or revoking their client authorization. Not a role change.
Run it early
The preflight is readable on its own, before anybody is removed. It answers, for a given person, which connections will need resolving and what depends on them.
Run it a week before the last day, not the morning after.
While the person is still here, they can tell you which of their four connections matters and which was a one-off from a project that ended. After they have gone, somebody is reverse-engineering that from a toolbox name, and what should have been five minutes becomes an afternoon and a few wrong guesses.
Not creating the problem in the first place
Everything above is recovery. The arrangement that avoids most of it is a decision made at connection time, and it costs nothing then.
Connect a system under the identity that owns the system. The person who administers the helpdesk connects the helpdesk. Not the first support agent who wanted it, however willing they were. The credential then belongs to a role somebody inherits rather than to a person who leaves.
Share to a team, not to a list of people. Sharing to a team means joiners and leavers are handled by team membership, which somebody already maintains. Sharing to eleven named individuals means eleven decisions every time the team changes, and the eleventh is the one that gets missed.
Prefer a credential that is not personal where the vendor allows one. Some vendors issue tokens tied to a service identity rather than to a human account. Where that exists and is genuinely scoped, it removes this whole failure mode. Where it does not, note that the connection is personal so the next person to look at it knows.
Write down why a connection exists. A connection named after the system, shared with the team that uses it, with a sentence about what depends on it, is the difference between a five-minute offboarding decision and an afternoon of reverse-engineering.
None of this helps with what is already connected, which is why the preflight exists. It does mean the set of connections that need resolving stops growing.
A checklist
- Run the preflight during notice, not after.
- Ask the person which connections matter. They know; nobody else does.
- Transfer team resources, delete personal ones. Do not transfer by default.
- Re-point delegated entries in shared toolboxes. It is an edit, not a credential decision.
- Confirm the tooling still works with someone who uses it daily, before the account is gone.
- Look at the audit trail afterwards for calls made through the connections you kept, and check they are what you expected.
The access model underneath this is in the access model this sits on, and the trail that step six reads is described in what an AI audit log has to capture. If you are setting up shared connections in the first place, what teams do with Elaichi shows the arrangements that tend not to create this problem.
