Offboarding Employees From AI Agent Tools: A Same-Day Checklist

Offboarding an employee from AI agent tools means removing everything that person could use to direct an agent on the day they leave: approval rights, shared memory they shaped, and tools their credentials or grants can reach. Work from a written list of every agent role, approval queue, memory space and connection tied to that person, then reassign, revoke and verify each item before the end of the working day. The checklist below follows that order, so nothing is revoked before its replacement is in place.

Key takeaways

• Treat agent approvals, shared memory and connected tools as access that ends on the departure day, the same way email and file shares do.
• Reassign pending approvals before revoking the departing person's authority, so no agent action stalls or runs without review.
• Separate company knowledge from personal drafts in shared memory, and decide what happens to each part explicitly.
• Rotate shared credentials the person created or held, not only their own login.
• Keep a short written record of what was removed, by whom and when, and check the activity log the next morning.

Why an agent account is not the only door

Most offboarding routines stop at the identity provider. The login is disabled, the laptop is collected, and the person leaves the team chat. Agents can keep acting after that if the person's approval rights, delegated grants or tool connections were never cleared. A manager who approved agent purchase requests may still be the named approver in a workflow. A connector authorized under their name may still write to a customer record. Instructions they wrote into shared memory may still shape every future run.

It helps to think of agent access in three layers. The first is authority: who can approve, reject or override an agent's action. The second is memory: what the agent stores and reuses across tasks. The third is reach: which tools the agent can call, and with which credentials. Each layer has its own removal step, and a clean login alone clears none of them.

The same-day checklist

Assign one owner for the whole list, ideally the manager with authority over the departing person's work. Start before the final hour if the departure date is known in advance.

• Freeze new approvals: mark the departing person's approver role inactive in every agent workflow, and note any requests still waiting in those queues.
• Build the inventory: list every approval queue, memory space, scheduled agent task and connected tool where the person appears as owner, approver or creator.
• Reassign pending approvals: name a successor for each queue, with a short note on what that person now approves and what the limits are.
• Split the memory: mark which notes and examples are company knowledge and which are personal drafts or private preferences.
• Move company knowledge to a shared owner, and remove personal drafts after a quick review.
• Revoke personal grants: remove the access the person gave agents to their mailbox, calendar, CRM or file storage.
• Rotate shared credentials: if the person created or knew a service credential that agents use, issue a new one and update the tool configuration.
• Pause or reassign scheduled jobs that they own or that send outputs to their address.
• Test the removal: attempt an action as the departing identity and confirm it is refused.
• Write the removal record: what was removed, what was reassigned, who did it and when.
• The next morning, check the agent activity log for any action taken under the departed identity after the revocation time.

Approvals: reassign before you revoke

Approval rights deserve the most care because they let one person's judgment keep steering agent actions after they have gone. If you revoke first, the queue can freeze, and the agent may escalate to a channel that nobody monitors. If you reassign without a record, it becomes unclear who approved what, and that gap is hard to close later. The order that works is: list pending items, name a successor for each, confirm the successor has seen the items, and only then remove the old approval role.

Illustrative scenario: a procurement lead leaves on a Friday. She is the named approver for an agent that drafts supplier orders below a set limit, and three orders are waiting. On Friday morning the operations manager reviews each draft against the limit, approves or rejects it with a note, and then the lead's approval role is removed. On Monday, the agent has an approver assigned to every queue, and no order is waiting on someone who no longer works there.

Shared memory: keep what the company needs, remove what only the person used

Agent memory is often the least visible part of offboarding. Over months, a team member may teach an agent how to format reports, which customers need a particular tone, or how to handle exceptions. Some of that knowledge belongs to the company and must stay available to the team. Other parts are personal scratch work, private preferences or notes that contain personal data about colleagues or customers, and those need a removal decision under your privacy rules.

The departing person can usually tell you which notes they wrote for their own convenience. Your manager can tell you which notes the team depends on. Record the decision for each item, because a memory space with an unlabeled author is hard to clean up later. If a note contains personal data and must go, follow your deletion procedure rather than editing it informally. The steps for finding and verifying removal are covered in deleting agent memory on request.

Connected tools and credentials that outlive the person

Three kinds of connection need attention. The first is personal grants, where the person authorized an agent or agent platform to read or write their mail, calendar, files or CRM records. The second is service credentials, such as API keys or service accounts they set up or know. The third is scheduled jobs and webhooks that post results to their address or depend on their login.

Revoke each personal grant in the tool's own administration console, and confirm the revocation there instead of assuming the agent platform has dropped it. Google's OAuth 2.0 documentation explains how client authorization and access tokens work, which is useful background when you check whether a grant still exists. For agents that reach tools through a standard interface, review which tool servers each agent can call, since the Model Context Protocol introduction describes how these connections expose tools to a model. Remove the departing person from any tool server configuration that lists them as the owner.

Be Human's managed approach treats this as a standing operating step rather than a one-time cleanup. The engagement begins by mapping which agent roles, memory spaces and connections each person can reach, so the departure list already exists when someone leaves. Monitoring watches for activity under retired identities, and permission reviews run on a fixed schedule. The company keeps control of approval boundaries and tool permissions, and it decides who inherits each one.

Verify the removal and keep a record

A checklist is only as good as its verification. Where the tool allows it, test from the departed identity's point of view, and confirm that the attempt is refused with a clear message rather than silently queued. Then check the activity log for the period after the revocation time, looking for approvals, writes, sends or memory changes attributed to the old identity. If the log shows anything, treat it as an incident and follow your response steps before closing the ticket.

Keep the removal record with your access review file, not in a chat thread. It should name the items removed, the successors assigned, the credentials rotated and the people who confirmed each step. Keep it free of personal details beyond what your retention rules require. The OWASP Authorization Cheat Sheet gives useful guidance on checking that access decisions are enforced at the point of action, which is the test that matters here. Offboarding is complete when a refused action and a clean log can both be shown, not when someone says it is done.

If you are not sure which agent tools a departing employee can still reach, take the free Be Human AI diagnostic to find the first task worth handing to an agent and the access questions to settle before it goes live.

Frequently asked questions

Should we remove agent access before the employee is told they are leaving? Prepare the inventory and reassignment list in advance, then act at the point your HR and legal process treats the decision as final. Preparing early keeps the handover calm and avoids a gap in approvals on the last day. The removal itself should happen on the departure day, not weeks later.

Who owns the memory an employee built up with an agent? Ownership depends on your employment terms, your acceptable use policy and the rules of the agent platform you use, so answer it in writing before you need the answer. In most companies, knowledge that supports company work belongs to the company, and personal material belongs to the person. The article on who owns AI-generated work sets out the questions to settle.

What if the person's approvals were used heavily in the months before they left? Include a look-back in the access review, not only the departure list. Sample the approvals they gave, check whether the limits were respected, and note any pattern that needs correction. This is a normal part of a quarterly permission audit, and it helps you decide whether the workflow's limits were set correctly from the start.

Do contractors and temporary staff need the same checklist? Yes, with the contract end date as the trigger. Contractors often hold service connections and personal grants that are easy to forget, so their inventory deserves extra attention. Record the end date when the contract is signed, so the removal list is ready before the work finishes.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.