Offboarding Employees Who Used a Company AI Agent: A Plan

To offboard an employee who used a company AI agent, remove their access to the agent and to every tool the agent reached on their behalf. Then decide what happens to their personal memory, move shared work to a named owner, and document the handover. Do this on the last day, not the week after, because delegated permissions and saved context keep working until someone turns them off.

Key takeaways

• Standard offboarding covers email, laptop and chat. It usually misses the agent's delegated permissions, saved memory, scheduled tasks and approval rights.
• Revoke access in a fixed order: stop the person from instructing the agent, revoke the grants they made, then clean up what the agent still holds in their name.
• Sort personal memory into categories (company knowledge, working preferences, private content, legal hold) instead of deleting or keeping everything.
• Shared work should belong to a role or a team, never to an individual. Offboarding is when you find out whether it does.
• A handover covers what the person taught the agent, what is still in flight and where the approval boundaries sit, not just a list of files.

Why does an agent change the offboarding checklist?

A traditional offboarding checklist assumes that a person's access lives in accounts: email, shared drives, the CRM, the chat tool. Disable the accounts and the access is gone. A company AI agent adds a layer that those accounts do not describe.

An agent used by several people typically holds four things that are tied to individuals. First, delegated permissions: the person may have connected their calendar, mailbox or documents so the agent could act for them. Second, memory: preferences, corrections, notes about contacts and context from months of use. Third, automations: scheduled tasks, triggers and recurring reports that someone set up and nobody else remembers. Fourth, approval rights: the person may be the one who confirms when the agent wants to send something external or change a record.

None of these disappear when the employee's directory account is disabled. Some stop working in confusing ways, such as a recurring report that fails silently. Others keep working, such as a token that was granted separately. The goal of offboarding is to make the outcome deliberate in both cases.

If you are still working out how the pieces of your setup fit together, the seven layers of company AI infrastructure is a useful map of where identity, memory and tools each live.

Which access should you remove, and in what order?

Order matters because some steps depend on others. If you delete the person's memory before you check what it contains, you lose information the team may need. If you revoke their tool grants before you list the automations that use them, you break workflows without knowing which ones.

Use this sequence on or before the last day:

• Stop new instructions. At the identity provider, suspend the person's ability to sign in to or message the agent through any channel (chat, email, web, phone). Do this at the agreed departure time, not earlier unless the departure is contentious.
• Inventory what is connected in their name. List every integration the person authorized for the agent: calendar, mail, drive, ticketing, CRM. These are typically OAuth grants, and the [OAuth 2.0 documentation from Google](https://developers.google.com/identity/protocols/oauth2) explains why a grant outlives a password change unless it is revoked explicitly.
• Revoke those grants. Remove each delegated authorization and confirm the agent can no longer act in that person's mailbox, calendar or files.
• Review approval and escalation routes. Replace the person wherever they were the approver or the contact the agent notifies. An approval that goes to a disabled account is a stalled workflow.
• Reassign or stop scheduled tasks. Every recurring job or trigger the person created gets a new owner or is retired on purpose.
• Rotate shared secrets. If the person knew any credential used by the agent or its tools, change it. Individual credentials are revoked, shared ones are rotated.
• Check the logs. Confirm that no active session, token or channel membership remains, and record the date and who verified it.

The underlying principle is the one in the [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html): deny by default, grant by role, and review permissions when circumstances change. A departure is exactly such a circumstance.

This is far easier when the agent has its own identity and accounts rather than borrowing a person's. If the agent acts through a named employee's login, removing the employee can break the agent or, worse, force you to leave the login alive. The reasoning is covered in why your company AI agent needs its own identity and accounts. A related point is who holds the model account and keys, discussed in who owns AI API keys in a business.

What should happen to the person's personal memory?

Personal memory is whatever the agent retained from working with that individual: their stated preferences, corrections they made, notes about their clients or suppliers, drafts, and conversation history. It is mixed material. Some of it is company knowledge that happens to be stored under one person's name. Some of it is private. Treating all of it the same way, in either direction, causes problems.

Handing the whole memory to a successor transfers private content and another person's habits. Deleting all of it throws away operational knowledge. Sort it instead. This decision guide works for most teams:

• Company knowledge (client status, process notes, supplier terms, decisions and their reasons): review it, then promote it into the shared knowledge the team's agent role uses. Someone with authority over that function approves what moves.
• Working preferences (tone, formatting, how this person liked summaries): archive or delete. A successor should set their own, and the agent should not behave as if the new person were the old one.
• Private or personal content (personal messages, non-work calendar entries, anything unrelated to the job): delete or return according to your policy and the data protection rules that apply to you. In Brazil, the [ANPD](https://www.gov.br/anpd/pt-br) is the authority to consult for personal data obligations. Ask counsel to confirm what applies in your case.
• Material under legal or regulatory hold: preserve it in a restricted location with named access, and record why.
• Anything you cannot classify: quarantine it with a named reviewer and a set review date, rather than guessing.

Two practical notes. First, make the rule before anyone leaves. People are more candid about what they store when they know the policy. Second, ask your provider where personal memory is stored and how it is deleted, including backups and any search indexes derived from it. Deleting the visible record while an index still returns it is not deletion.

How do you protect shared work the person created?

Shared work is anything others rely on that the departing employee authored or owns: prompts and instructions, saved workflows, document templates, knowledge collections, dashboards, automations. In many companies these items carry the creator's name as owner, and nobody has ever checked.

Before the last day, run an ownership sweep:

• List every asset where the departing person is the owner, editor or only maintainer.
• For each one, record who depends on it, how often it runs and what breaks if it stops.
• Assign a new owner that is a role or team (for example, the operations lead), not another individual who may leave next.
• Test one run of each critical item under the new owner's permissions, because an automation that worked under the old owner's access may fail under a narrower one.
• Write a one-line purpose beside each asset, so the next owner knows why it exists.

This sweep tends to reveal two things. Some assets nobody uses and nobody will miss; retire them. Others turn out to be load-bearing, and the only person who understood them is leaving. That is the signal to schedule a short working session before departure, not a document someone writes in a rush on the final afternoon.

Ownership by role is a governance habit, not an offboarding trick. If you want a lightweight structure for it, AI governance for mid-sized companies outlines a starting point, and a RACI for company AI agents shows how to record who is responsible for each part.

What does a good handover cover?

A handover for agent work is different from a handover of files. The departing person has been shaping the agent's behavior, often without noticing: correcting its output, adding instructions, deciding what it may and may not do. That tacit knowledge is the valuable part.

A useful handover conversation, ideally in the final week, covers:

• What the person asks the agent to do regularly, and what a good result looks like.
• Which corrections they made most often, since these point to weaknesses in the agent's instructions or knowledge.
• Tasks in flight: what is half done, what is waiting on someone, what is scheduled.
• Approval boundaries: what the agent may do alone, what needs confirmation, and who confirmed it.
• Known failure cases: situations where the agent was unreliable and the person worked around it.
• External contacts or systems that expect to hear from this person, and who they should hear from now.

Write the result as a short note attached to the agent's role description, not buried in an email. If the role itself changes because of the departure, update the description and the success measures too. The job description for an AI agent role is a useful format for that.

A successor should then start with a clean personal memory and the promoted shared knowledge. Let them build their own working preferences. Rebuilding is cheaper than untangling someone else's habits from the agent's behavior.

What does this look like in practice? An illustrative scenario

This is an illustrative scenario, not a description of a real engagement.

An operations coordinator at a small distribution company is leaving. She used the company agent to prepare weekly supplier summaries, draft reorder emails and keep notes on delivery problems by supplier. She had connected her mailbox and calendar so the agent could draft in her name and schedule calls.

Two days before her last day, the operations lead runs the sequence above. The lead lists her grants (mailbox, calendar, shared drive) and her two scheduled jobs: the weekly summary and a Monday reminder about open purchase orders. In the memory review, the supplier delivery notes are marked as company knowledge and promoted to the shared supplier collection after the lead checks them. Her formatting preferences are archived. A handful of personal calendar entries are deleted under the company policy.

In the ownership sweep, the lead notices that the weekly summary template is owned by the coordinator alone. It moves to the operations team as owner, and the lead runs it once under their own permissions to confirm it works. At the end of her last day, her sign-in to the agent is suspended, the mailbox and calendar grants are revoked, and the lead records the date. The successor starts the following week with a fresh personal memory and the shared supplier notes already in place.

Nothing in this scenario required special tooling. It required a list, an owner and the habit of doing it on schedule.

How does Be Human handle this?

Be Human designs agents with their own identity, memory, channels, tools and permissions, kept under the client's control, so a departing employee can be removed without disturbing the agent itself. Offboarding is defined as part of the first engagement alongside the role, the approval boundaries and the success criterion. In managed operations, permission review and integration maintenance cover what the checklist above needs: finding delegated grants, reassigning approvals and confirming that access is gone. The client decides what happens to personal memory and who owns shared work. Be Human documents those decisions and carries them out. Details of the recurring work are in what managed AI services include.

Frequently asked questions

Should we offboard the agent access before or after the employee's last day? Suspend the person's ability to instruct the agent at the agreed departure time, and run the inventory and handover beforehand. Revoking too early can block the handover itself, and revoking too late leaves delegated access open. For a contentious departure, move the suspension earlier and run the inventory without the person.

Can a successor inherit the previous person's agent memory? Only the parts that are company knowledge, after review. Working preferences and private content should not transfer, because the agent would behave as if the successor were the predecessor, and personal data would reach someone with no need for it. Promote the useful knowledge to a shared collection and let the new person start clean.

Who is responsible for offboarding agent access, HR, IT or the team lead? Assign it explicitly, because without an owner each group assumes another has done it. A common split is that HR triggers the process, IT or the managed provider revokes access, and the team lead approves what happens to memory and shared work. Record this in your RACI so it does not depend on who remembers.

What if we discover the departed person owned an automation nobody understood? Pause it, do not delete it, and check what depends on it. Then assign a role-based owner, document its purpose and test it under the new owner's permissions. If nobody can explain it and nothing depends on it, retire it deliberately and note the decision.

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