Access that outlives the job
is the breach nobody noticed yet
A former employee who still has access to the CRM, the codebase, or the shared drive a month after leaving is one of the most common and most preventable security gaps there is. We build an agent that maps who has access to what across your actual systems, flags anything that no longer matches a role, and walks through a full revocation checklist the day someone leaves.
The process today
Offboarding an employee usually means a checklist someone in IT or HR works through by hand: disable the email account, remove them from the main systems everyone remembers, and hope that covers it. What gets missed is almost always the same: a shared login to a marketing tool nobody tracks centrally, access to a code repository granted individually rather than through the main identity provider, a service account someone set up under their own name years ago and forgot about, a shared drive folder that still shows their name with edit access.
The second cost is timing. Even a thorough manual offboarding often takes days to actually complete across every system, because it depends on someone with the right permissions in each tool getting to the request, and in the meantime the departing person’s access is still live, which matters most exactly when the departure is not an amicable one.
The third is that access reviews, the audit of who currently has access to what and whether it still matches their role, tend to happen once a year if at all, usually scrambled together right before a compliance audit, rather than as an ongoing discipline that would catch access drift long before it becomes a finding.
What the agent does
The agent builds and maintains a map of who has access to what across your identity provider, email, code repositories, cloud consoles, shared drives and the other tools your team actually uses, not just the ones that come to mind first. On a quarterly cadence, it reviews that map against current roles and flags anything that no longer fits: someone with admin access they needed for a project that ended months ago, a contractor whose engagement ended but whose login never got removed.
The moment someone is marked as departing, whether through your HR system or a direct instruction, the agent runs the full offboarding checklist same day: disabling or transferring access across every connected system, including the shared and service accounts a manual process usually misses, and logging a confirmation for each one. Where access needs to transfer rather than disappear, a shared drive a departing manager owned, that is handled as an explicit, logged exception rather than falling through the cracks. Typical integrations: Google Workspace or Microsoft 365, Okta or another identity provider, GitHub or GitLab, AWS or GCP consoles, and your HR system for the trigger.
What stays with humans
Defining what access each role should actually have is a decision your team makes, not something the agent infers from current access patterns, since current access often already includes drift the review is meant to catch. Any access transfer involving sensitive data, a departing finance lead’s spreadsheets, for example, gets a named human approver before the transfer happens. Deciding how to handle a contentious departure, timing, communication, any legal considerations, stays entirely with HR and leadership; the agent executes the technical revocation on their instruction.
Guards
Every access review and every offboarding action is logged with a timestamp and confirmation that the revocation actually completed, not just that a request was sent, so an audit has a clear, provable record. Access transfers are flagged explicitly and require a named approver rather than happening silently. A kill switch pauses automatic revocation for a specific case that needs special handling, such as a departure under legal review, without disabling the rest of the review and offboarding process.
Price and timeline
| Option | Price | What it covers | Timeline |
|---|---|---|---|
| Single automation | from $700 | Core systems, quarterly review, day-one offboarding checklist | 1 to 2 weeks |
| Department package | from $2,000 | Access reviews plus secrets rotation and dependency vulnerability scanning | 2 to 4 weeks |
Running cost is usually $10 to $30 a month in model and API usage depending on headcount and tool count.
Related
This pairs well with secrets rotation since a departing employee’s access and the credentials they could have seen are part of the same risk, and with dependency and vulnerability scanning as part of a broader security hygiene program. For the compliance record this produces, see log retention and compliance. Full package details are on the AI agents service page and the automation-everything overview; for security work on infrastructure we run ourselves, see the secure infrastructure case study and the secure messenger case study.
Not sure who still has access to what after the last few departures? Get in touch and we will map your current access footprint.
Tired of doing this by hand? We can take the whole routine off your team, not just this step: Routine takeover, from $400 →
FAQ
How much does access review and offboarding automation cost?
From $700 covering your core systems, identity provider, email, code repos and shared drives, live in 1 to 2 weeks. A larger tool footprint usually runs $1,200 to $2,000.
What triggers the offboarding process?
Typically a status change in your HR system or a specific message to the agent; either way, revocation across every connected system starts the same day, not whenever IT gets to the ticket.
What about shared accounts and service accounts, not just individual logins?
These are specifically included because they are the most commonly missed in a manual offboarding checklist: a shared marketing tool login, a service account someone set up personally, an API key tied to a departing engineer's name.
Does it decide who should have access to what?
No, your team defines roles and what access each role should have; the agent audits actual access against that definition and flags mismatches, and executes revocation you have approved for the offboarding case.
What if someone needs their access transferred rather than revoked, like a departing manager's shared files?
That is handled as an explicit exception in the checklist: a transfer step to a named successor instead of a straight revocation, logged the same way as any other action.