How we handle offboarding when someone leaves
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.
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
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.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail