How we offboard employees
On a schedule, an agent checks for newly marked departures and runs the offboarding checklist across Okta, Google Workspace, Google Drive, and GitHub — revoking access, transferring ownership, and reclaiming licenses — holding the ownership transfer for approval and never deleting an account.
Offboarding is a checklist that has to run to completion. When someone leaves, their access has to be revoked everywhere, their documents and repositories have to change hands, and their licenses have to come back. Miss a step and a former employee keeps a login, a shared drive loses its owner, or a paid seat sits unused. The steps are simple; the risk is in the ones that get skipped.
We run offboarding through an agent on Kortix. On a schedule, the agent checks for newly marked departures and works the checklist across every connected tool, posting what it did and what is still pending. This is the security counterpart to how we onboard.
The problem
When an employee leaves, their access has to be pulled from every system they touched, their work has to be handed off, and their licenses have to be reclaimed. That means Okta, Google Workspace, Slack, and GitHub, each with its own steps, done in the right order, on the same day.
The common approaches leave gaps. A written runbook depends on someone working it by hand under time pressure, and a missed line is a live account no one notices. A provisioning tool covers SSO but not document ownership or repository access. IT tickets spread the work across people and days, and the parts that are easy to forget are exactly the ones that matter for security.
What we built
On Kortix, an agent checks Okta on a schedule for newly marked departures. Each check spawns an isolated session (a cloud sandbox) with scoped access to Okta, Google Workspace, Google Drive, and GitHub, and works the offboarding checklist for every departure it finds: revoke SSO and app access, remove the person from the GitHub org, transfer document and drive ownership, and reclaim licenses. The ownership transfer waits at a human approval gate — account deletion is never attempted — and the agent posts a completed checklist showing what it did and what is still pending.
How it works
Check Okta on a schedule
The agent checks the Okta group HR adds departing employees to on a schedule, so access comes down the same day a departure is marked. Each check spawns a fresh session in its own sandbox; if it finds more than one new departure, each is worked as its own independent case, and nothing carries over between runs.
Give the agent the offboarding checklist
Our offboarding policy lives as skills and memory that travel with the agent: the full list of systems, the order to work them in, which steps are reversible and which are not, and how ownership should be reassigned. When we add a tool or change a policy, we write it down and the agent picks it up on the next departure.
Connect the systems access lives in
Through scoped connectors, brokered server-side so no raw token reaches the model, the agent can:
- Revoke SSO in Okta — deactivate the account and pull the app assignments that hang off it. Access to Slack drops the moment SSO is revoked, where Slack is SSO-connected.
- Remove from GitHub — remove the person from the GitHub org and its teams.
- Transfer ownership in Google Drive, then suspend in Google Workspace — reassign document and shared-drive ownership so nothing is orphaned, then suspend the account.
- Reclaim licenses — release paid seats across the connected tools so they return to the pool.
Set the guardrails
The reversible steps run on their own; transferring ownership away from a person stops at a human approval gate before it executes. Account deletion is out of scope for this agent entirely — it is never performed, gated or otherwise, and hands off to a human if one is ever genuinely needed. Credentials are encrypted in the Secrets Manager and injected at runtime, never shown to the model or written to logs.
Run the checklist to completion
With that in place, each departure the scheduled check finds becomes one worked case: SSO revoked, GitHub access removed, ownership transferred, and licenses reclaimed, with the ownership transfer held for approval. The agent posts a completed checklist showing every step it took and anything still pending a human, so nothing is left half-done.
The pattern
A scheduled trigger spawns a session with scoped connectors into Okta, Google Workspace, Google Drive, and GitHub. The offboarding policy is encoded as skills and memory. The agent runs the reversible steps on its own and holds the ownership transfer behind a human.
Guardrails
The agent revokes access and transfers ownership across every system, so the access is scoped and contained:
- Isolation. Every departure case runs in its own microVM sandbox. The session can reach only the systems it's scoped to, and only the checklist result leaves the sandbox.
- Scoped secrets. The Okta, Google Workspace, Google Drive, and GitHub credentials are encrypted in the Secrets Manager and injected into the sandbox at runtime, never exposed to the model or the logs.
- Human approval gate. Transferring ownership away from a person requires a person to approve before it runs.
- Never deletes. Account deletion is out of scope for this agent entirely — it is never performed, gated or otherwise. It hands off to a human if a deletion is ever genuinely needed.
- Everything is code. The agent's checklist, skills, and per-system permissions are files in the repo, versioned and changed through a reviewed change request rather than a dashboard setting.
The outcome
Access that used to depend on someone working a runbook by hand now comes down the same day a departure is marked, with ownership transferred and licenses reclaimed in the same run. The ownership transfer waits for a person, and the completed checklist shows exactly what happened and what is still pending.
Read more
How we keep our docs in sync with the code
The docs agent we run on Kortix — connected to GitHub and our codebase. Once a day it checks the code that landed since its last run and updates the docs those changes affected, opening a PR for review.
How we QA every pull request automatically
The QA agent we run on Kortix — connected to GitHub and our test environment. It checks out each PR, runs the suite, exercises the change, and posts the result.
How we run operations from Slack
A single agent reachable from Slack, with scoped access to our database, Stripe, Linear, and GitHub. Ask in a thread and it runs the task across whatever platforms it needs.
Engineer your first loop
Give your company a workforce of agents that run on a schedule, ship real deliverables, and improve one reviewed change at a time. Free to self-host, managed cloud from $20.
Open source · SSO · RBAC · on-prem · no lock-in