Disabling the account ends their login. It doesn't touch what they built, or tell you what they ran.
Your best SRE leaves on a Friday. IT disables their identity-provider account, closes the ticket, and the offboarding control goes green. Still running on Monday morning: the personal API token they minted for the deploy pipeline, the service account behind the nightly job, the MCP integration they wired into a coding agent, and a local account on four hosts that predates everyone still on the team.
You offboarded a person. You didn't offboard anything they built. And if an auditor asks what that person executed on production over the last three years, nobody in the room can answer.
The recurring shape here isn't "we forgot to revoke." It's "we revoked the login and assumed that was everything"—the same gap an agent's attack surface exposes from a different angle. This post is about the two halves a checklist can't reach: the non-human identities a departure orphans, and the execution record that makes revocation provable.
What actually survives when you disable the account?
TL;DR: The account dies; almost nothing else does. Tokens, service accounts, and agent integrations the person created keep authenticating on their own credentials—and OWASP ranks improper offboarding as the #1 non-human identity risk.
When OWASP published its Non-Human Identities Top 10, the #1 slot didn't go to leaked secrets or overprivileged roles. It went to improper offboarding, and one of the sub-cases it names is exactly this one: "the original owner departs, but the associated NHIs remain active without a new designated owner."
That tracks what a senior engineer's footprint looks like in 2026. It isn't a login. It's a pile of things that authenticate without them: CI credentials, cloud service accounts, webhook secrets, and increasingly agents and MCP integrations running under their authority. Machine identities already outnumber humans by as much as 144:1 in cloud-native environments (Entro Labs); broad-enterprise figures run lower, in the 45:1–80:1 range.
The Cloud Security Alliance's non-human identity research puts a sharper number on this exact moment: 8% of enterprise identities have no HR-system ownership linkage once their creator departs (originally reported by The Hacker News, cited in CSA's whitepaper), and CSA reports 51% of organizations have no clear ownership of AI identities. Those aren't credentials someone decided to keep. They're credentials that outlived the only person who knew what they were for.
Why does disabling the identity provider stop at the tool boundary?
TL;DR: Federation governs the login, not the credentials a user mints inside each downstream tool. CSA found only 20% of organizations have a formal process for offboarding and revoking API keys.
Single sign-on ends a person's ability to start a session. It says nothing about a personal access token minted inside a downstream tool, which presents itself directly to that tool's API with no round trip to the identity provider—there's nothing for the disabled account to break. Revocation stops at the edge of the identity provider unless you have a deprovisioning path into every system with its own credential store. CSA puts the share of organizations with a formal process for offboarding and revoking API keys at 20%.
The clearest public case this year is Klue. TechCrunch reported in June 2026 that a credential issued to a third party in 2022 for a limited pilot was never revoked; Klue described it only as "a legacy credential associated with an integration service" and declined to say what format it took. The extortion group Icarus used it roughly four years later to reach Klue's platform and take the OAuth tokens customers had authorized for connected third-party platforms, then queried their CRM data directly. Two of the named victims sell to security teams—LastPass (per TechCrunch) and Huntress, which published its own incident report—alongside Recorded Future, Tanium, Jamf, Sprout Social, Gong and Insurity.
Klue is a project offboarding failure rather than a people one: the pilot ended and the credential didn't. Same lifecycle gap, one degree over, and worth sitting with because it hit vendors that serve security teams.
Can you prove the revocation actually worked?
TL;DR: Not without an execution record. SOC 2 CC6.2 wants documented, timely evidence that access was terminated, and "what did this person run for three years" is unanswerable if nobody recorded execution.
There are two offboarding questions. "Did we revoke their access?" is the one every checklist answers. "What did they run while they had it?" is the one the auditor asks, and almost nobody can answer it—because revocation is a state you assert, and execution is a record you either kept or didn't.
SOC 2 CC6.2 covers user access termination, and auditors treat it as an evidence control: documented, timely, consistently applied. A former employee with an active account is a standard immediate finding. But the attestation covers the process, not the record of what happened under that access. A ticket saying the account was disabled on the fifteenth says nothing about the three years before it.
That gap gets measured in months. In the Coupang breach disclosed in December 2025, a former employee who left in 2024 retained access to internal systems; the breach occurred on June 24, 2025 and wasn't discovered until November 18, exposing 33.7 million customers. Public reporting doesn't say how the access was retained. The timeline is the point—left in 2024, abused in June 2025, discovered that November: a roughly 147-day detection gap that still beat the 194-day industry mean time to identify a breach (IBM Cost of a Data Breach 2024). Typical is the problem.
What belongs in an offboarding runbook that a checklist misses?
TL;DR: Six steps, every one about what the person created rather than the account they logged in with.
- Enumerate before you revoke. Pull every non-human identity the person created or last owned—API tokens, service accounts, CI credentials, agent and MCP integrations—before the account is disabled. Once it's gone, the ownership link usually goes with it.
- Reassign ownership; don't just delete. OWASP's orphaned case is an identity with no designated owner. Every survivor needs a named human successor or an explicit, recorded decommission decision. "Nobody complained" is not a decision.
- Revoke per tool, not just at the identity provider. Every system that lets a user mint its own credential holds its own token store. That's a separate revocation step per system, and it's the one that gets skipped.
- Check last-used before you touch anything. A token idle for 90 days is a decommission candidate. A token used an hour ago is a production dependency, and pulling it on a Friday evening breaks the nightly job.
- Separate accounts you created from accounts you inherited. Deleting
ubuntuor a shared operator account because a leaver was bound to it takes everyone else's access with it. Unbind the identity; keep the account. - Keep the execution record. If the only artifact of three years of production work is a shell history file on a host that's since been reimaged, you have no answer to the auditor's question.
Where does execution control change the shape of this problem?
TL;DR: If privilege only exists inside a declared, recorded session—with two named exceptions—there's less standing grant left to forget, and the layer that governs the command is the layer that produces the evidence.
Steps 1 through 5 are inventory problems; step 6 is an execution problem. All of them get easier when access isn't a durable grant in the first place. In Alpacon, user and agent actions belong to a Work Session with a declared scope, and every action lands inside a scoped, recorded session. Sessions are time-bound and expire automatically unless extended, so grants don't linger by default. Either way, the leaver's ability to start a new one ends only when someone removes their access in Alpacon.
The inventory half: provenance and token hygiene
Account provenance is the base layer we've written about as a general property of zero standing privilege; here it's runbook step 5. Local accounts Alpacon discovers or provisions carry an origin classification, so when a person's last access is removed, the ones Alpacon provisioned are deprovisioned automatically and the ones it didn't (ubuntu, root, shared operator accounts) are unbound from the departing identity instead of deleted—enforced by the system instead of by whoever is on the offboarding rotation.
Personal API tokens are where the runbook's step 4 gets real data instead of a guess: last-used visibility, stale-token flagging, and in-place rotation are shipped. Token-run commands get the same runtime risk assessment as human-typed ones, and every command and file transfer is attributed to the exact token that ran it. A personal API token's privileged execution is risk-assessed and attributed today; requiring it to sit inside a declared work session is designed and staged, not yet the default.
The execution half: attribution and what's still rolling out
That attribution is step 6. Session recording plus execution audit means the record isn't "the account was disabled on the fifteenth"—it's which commands ran, on which host, under which identity and which credential, for the whole time the person was there. That's the record CC6.2 attestation can't give you, and unlike a ticket, it can't be produced retroactively.
There's a forward-looking half too. A credential surviving somewhere in your estate is a fact of life; what it's allowed to do doesn't have to be. Every privileged action in Alpacon—human or agent, a sudo command or an agent's execute—passes one decision pipeline before it runs, and that pipeline can resolve to holding the specific action for a human's approval, not just the session it runs inside. Hard-deny on that path ships as a code release, so not every deployment blocks a high-risk command outright yet. Identity-layer offboarding doesn't reach that: a valid credential is still a credential nothing judges at the moment it acts.
What this still doesn't close
TL;DR: Alpacon doesn't consume a leaver event from your identity provider today. The trigger is still a deliberate action, and a few credential types sit outside the session model.
- No automatic deprovisioning from your identity provider. Signing in through your identity provider projects the identity provider's group memberships into Alpacon at that moment. That's a login-time event—it structurally cannot deprovision someone who will never sign in again. Propagating a leaver event from the identity provider down to the host is on the roadmap, not shipped. Today the trigger is removing the person's last access inside Alpacon, and that's still a step a human takes.
- Service tokens are a named exception. Distinct from personal API tokens, they remain long-lived and bounded by a static ACL rather than by a session.
- Scope-ceiling denial on out-of-scope
sudois on a monitor-then-enforce rollout, not enforce-by-default. Where enforce mode is on the out-of-scope action is denied; where it isn't, it's measured and recorded. - Alpacon governs the infrastructure it manages. The token your leaver minted in a SaaS console is still that vendor's deprovisioning path.
The takeaway
Deprovisioning removes the person. It doesn't remove what the person built, and it can't tell you what the person did. Treat offboarding as an inventory-and-evidence problem instead of a checklist problem, and both hard questions—what's still running under their name, and what did they execute—start having answers you can hand an auditor.
FAQ
What is offboarding access revocation? Removing a departing person's access at termination—done properly, that means the human account, every non-human identity they created or owned, and the evidence of what was executed before revocation.
Why isn't disabling the identity-provider account enough? Because single sign-on governs the login, not credentials minted directly inside a downstream tool—there's no round trip back to disable. Only 20% of organizations have a formal process for offboarding API keys (CSA).
What does SOC 2 CC6.2 require when an employee leaves? Documented, timely removal of access—an active account for a former employee is a standard finding. It doesn't require a record of what they executed while they had it; that takes session recording and an execution audit on top.
How do you find orphaned service accounts after someone leaves? Start from provenance rather than from the person: enumerate every account and credential by origin, owner, and last-used time, then flag anything whose owner is gone from HR. In Alpacon, local accounts Alpacon discovers or provisions on a managed server carry an origin classification and a managed flag, and personal API tokens show last-used visibility and stale flagging directly.
