# How we handle offboarding when someone leaves

A Machine agent checks Okta for new leavers, cuts their access in Okta, Google Workspace, Drive and GitHub and frees their licenses. Ownership transfers wait for approval; accounts are never deleted.

Canonical page: https://themachine.myapps.ai/use-cases/employee-offboarding

When someone leaves, every item on the offboarding list matters, and the list
is only safe once it is finished. Their logins need to close in every tool.
Their files and repos need a new owner. Their paid seats need to come back to
the pool. Skip one line and you get a former colleague who can still sign in, a
shared drive owned by nobody, or a license you keep paying for. None of the
steps are hard. The danger is the step that quietly never happens.

We hand that list to an agent on Machine. On a schedule it looks for anyone
newly marked as leaving, works through the list in each connected tool, and
reports what is finished and what still needs a person. Think of it as the
security-minded twin of our onboarding agent.

- **Team:** Machine
- **Runs on:** A scheduled look at Okta for new leavers
- **Connected systems:** Okta/SSO · Google Workspace · Google Drive · GitHub
- **Mode:** Runs on a schedule · ownership transfers need a yes

## The problem

A departure touches every system the person ever used. Access has to go, work
has to be passed on, and licenses have to be recovered across Okta, Google
Workspace, Slack and GitHub. Each tool has its own steps, they need to happen in
a sensible order, and all of it should be done on the day they go.

The usual methods have holes in them. A runbook on a wiki only works if someone
follows it line by line on a hectic day, and the line they miss is an open
account nobody spots. A provisioning tool handles SSO but knows nothing about
who owns which document or repo. Splitting it into IT tickets scatters the work
over several people and several days, and the easy-to-forget pieces are the
very ones security cares about most.

## What we built

On a schedule, a Machine agent checks Okta for people newly flagged as leaving.
Every check gets its own **session**: a fresh cloud computer (a sandbox) used
only for that run, with limited access to Okta, Google Workspace, Google Drive
and GitHub. For each leaver it finds, it works the full list. It switches off
SSO and app access, takes them out of the GitHub org, moves ownership of their
documents and drives, and frees their licenses. Moving ownership waits for a
person to approve it. Deleting an account is never on the table. When it is
done, the agent posts the finished checklist, including anything still waiting.

## How it works

### Look at Okta on a timer

HR drops departing staff into an Okta group, and the agent checks that group on
a schedule, so access is cut the same day someone is flagged. Every check starts
a fresh **session** on its own sandbox. Two or more leavers found in one check
are handled as separate cases, and no state is kept from one run to the next.

### Hand the agent your offboarding list

Our offboarding rules are kept as **skills** and **memory**, a playbook the
agent carries and keeps improving. It lists every system, the order to go
through them, which steps can be undone and which cannot, and who should inherit
the person's files. Add a new tool or change a rule, write it down once, and the
next leaver gets the updated treatment.

### Connect the tools that hold access

**Connectors** are scoped links to your tools. The keys stay on our servers, so
the model never holds a raw token. Using them the agent can:

- **Switch off SSO in Okta**: deactivate the account and strip the app
assignments hanging off it. If Slack signs in through SSO, the person loses
Slack at that same moment.
- **Take them out of GitHub**: remove them from the GitHub org and every team
inside it.
- **Move ownership in Google Drive, then suspend in Google Workspace**: give
their documents and shared drives to a new owner so nothing is left orphaned,
then suspend the account.
- **Free up licenses**: release their paid seats in the connected tools and put
them back in the pool.

### Decide what needs a human

Steps that can be undone just happen. Handing someone's files to a new owner
pauses at a **human approval gate** first. Deleting an account is simply not
something this agent does, with or without approval; if a deletion is ever
truly needed, it passes that to a person. Credentials are stored encrypted in
the **Secrets Manager** and only handed to the agents you grant them to.

### Finish the list every time

Now each leaver the check turns up becomes one complete case: SSO off, GitHub
access gone, files handed over and seats freed, with the handover held until
someone approves it. The agent then posts the checklist with every step it took
and anything still waiting on a person, so no departure is left half done.

> **The pattern**
> A timed **trigger** opens a session with scoped **connectors** to Okta, Google
> Workspace, Google Drive and GitHub. Your offboarding rules live in **skills**
> and **memory**. The agent does the steps that can be undone by itself and
> waits for a person before moving anyone's files.

## Guardrails

This agent pulls access and hands over files in every system you use, so we
keep its reach small and its work boxed in:

- **Isolation.** Each leaver is handled in a private sandbox. That session can
  only reach the systems it is scoped to, and the checklist result is the only
  thing that leaves it.
- **Scoped secrets.** The keys for Okta, Google Workspace, Google Drive and
  GitHub are stored encrypted in the **Secrets Manager**, passed into the
  sandbox when the run starts, and only handed to the agents you grant them to.
- **Human approval gate.** Before anyone's files move to a new owner, a person
  has to say yes.
- **Never deletes.** This agent does not delete accounts, full stop, approved or
  not. If one ever really has to go, it hands that job to a human.
- **Everything is code.** The checklist, the skills and the permissions for each
  system are files in the repo, tracked in version control. Changing them means
  a reviewed **change request**, not a dashboard switch.

## The outcome

- **Every departure:** Each leaver gets the whole list in every system
- **Same day:** Access cut as soon as the scheduled check spots them
- **4 systems:** Okta, Google Workspace, Google Drive and GitHub, one run

Cutting access used to rely on someone following a runbook by hand. Now it
happens on the day a person is flagged, and the same run hands over their files
and frees their licenses. The file handover still waits for a human, and the
posted checklist shows exactly what was done and what is left.