When Someone Leaves, Access Must Not Stay: Offboarding and Access Revocation for Vibe Projects

Setting the boundary first: this guide is about what happens after someone leaves

This guide covers a step that vibe projects often postpone until something goes wrong: when a team member leaves, how do you finish the handover and take back access cleanly? It runs in the opposite direction from the team-invitation and onboarding guide published in cycle135. That piece was about how someone joins; this one is about how someone leaves. The two complement each other and do not overlap. Three other published pieces need the same boundary drawn: account deletion is about a user closing their own account, role-based access control is about how a permission model is designed, and audit logs are about how logs are recorded and searched. This guide does not repeat the model or the log format; it covers only the sequence of hands-on steps that must be done, in order, when an internal collaborator departs.

Every example product and person below is fictional, invented only to make the process concrete — please do not map them onto any real project or real person. The core argument comes first: the worst failure in a departure handover is not "one item missed" but "we thought we were done, while one way into the system was still open". So this guide does not hand you a long checklist and stop. It gives you an order: cut external access first, then take back internal permissions, and finally run an audit. Get the order wrong, and even a long checklist can end up wasted.

A fictional example: where a three-person team's departure leaks most easily

Imagine a fictional three-person vibe project, "Lighthouse Ledger" (entirely fictional): its lead, A-Nan (a fictional person), runs product and releases; a collaborator, Xiao-Bei (a fictional person), runs backend and deployment; another collaborator, Xiao-Xi (a fictional person), runs frontend and design files. One day Xiao-Bei decides to leave, for the most respectable of reasons: not enough time, wanting to focus on their own work. The team's first instinct is usually "just remove their GitHub repository access and move on", and then everyone goes back to shipping features. Two weeks later the problems surface: the deployment server still accepts Xiao-Bei's personal key, a third-party email service's API key still sits in an environment file on Xiao-Bei's machine, the domain registrar's admin is still Xiao-Bei's personal email, and an unmerged branch still hides a temporary endpoint that only Xiao-Bei knew about.

This fictional example is not meant to suggest that Xiao-Bei is untrustworthy — quite the opposite. Most leftover access is not caused by malice but by convenience at the time: services registered under a personal email, keys tied to a personal account, configuration files that exist only on one person's laptop, contacts agreed verbally and never written down. All of it is invisible while collaboration is going well, and all of it becomes risk the moment someone leaves. The goal of a departure handover is not to guard against the departing person, but to move the project from "depending on what one person remembers" to "running without depending on any single person". That shift of mindset matters: a clean, dignified handover also protects the person who leaves — if anything goes wrong later, nobody will come back wondering whether they kept access.

Step one: a departure checklist, organised by "where can someone get in"

Do not build the checklist by brainstorming vendor names. Organise it by entry point, or you will miss things. The first category is identity and accounts: project email, collaboration tool accounts, code hosting accounts, design tool accounts, documentation and knowledge-base accounts. The second is secrets and credentials: API keys, cloud access keys, database passwords, deployment keys, secrets in continuous integration, webhook secrets for third-party services. The third is repository and code access: the main repository, side repositories, private dependency packages, deployment script repositories, infrastructure-as-code repositories. The fourth is third-party services: email delivery, SMS, payments, analytics, error monitoring, domains and DNS, SSL certificates, cloud storage buckets, hosted databases. The fifth is money and billing: cloud billing admin, payment platform admin, subscription payer, invoice recipient email.

Each item needs three things written after it: who holds it now, who it moves to, and how you will verify the move. Writing "done" is not enough; you must write the verification method. For domain control, that means: who it moves to, whether they can log into the registrar and change a test record, and whether it can be restored. For an API key, it means: do you revoke and reissue, or merely delete the old key from code? Deleting code without revoking the key is like changing a keyhole while the old key still opens another door. Secrets always follow three steps — revoke the old one, issue a new one, verify that the old one really no longer works — and missing any step means the item is not finished.

One category leaks most easily: things set up "in a personal name". Many vibe teams start fast, registering a domain under someone's personal email, building the first server under someone's personal cloud account, receiving verification codes on someone's personal phone. Nominally these are project assets; in practice they hang off a personal identity, and they are hardest to hand over when someone leaves. The principle is: transfer what can be transferred, migrate what cannot — move the service to a shared team email or team cloud account, then remove the old personal binding. If a service genuinely cannot be migrated, at minimum change the admin to a current member and replace the recovery email, backup codes, and billing contact, and leave a written record.

Step two: the handover pack — what the departing person should leave behind

A handover pack is not a work summary. It is a map that lets the next person keep working. It needs at least five things. First, work in progress: each open task's current state, next step, blocker, and who can unblock it. Second, unmerged branches: what each branch does, whether it can be merged directly, what tests it needs first, and which branches can simply be deleted. Third, where secrets live — not plaintext secrets in a document, but a clear statement of which secrets exist, which secret manager or environment they live in, and what the rotation procedure is, so the successor knows where to look and how to rotate, rather than receiving a string of passwords. Fourth, external contacts: domain registrar support, cloud vendor support, partner contacts, billing contacts for paid services, and vendors with a history of problems. Fifth, known traps: the things only the departing person knew, such as why a scheduled job runs at 3 a.m., why an endpoint waits an extra two seconds, or why a default configuration value must not be changed.

How the pack is delivered matters too. Ideally, schedule a handover session — in person or online — where the departing person walks the successor through it: opening the deployment console, running a release, looking at the monitoring dashboard, simulating a rollback. A document without a walkthrough is a map with no guide; many things never written down surface naturally during a live run. After the session, the successor should independently perform a key operation within 48 hours — for example, shipping a small change alone, or rotating a test secret alone. If they can do it independently, the handover has actually landed.

On timing, do not compress handover into the last day. The ideal rhythm is: list the checklist once the departure is confirmed, leave at least a week for handover and permission migration, and use the final day only for review and confirmation. If someone leaves suddenly with no buffer, reverse the emphasis: do the access revocation first (see the next step), then fill in the handover pack slowly. Never reverse that order — while you are slowly writing documentation, the access gaps are still open.

Step three: the order of revocation — why external access goes first

This is the most important section in the guide. The recommended order is: cut external access first, then take back internal permissions, and finally handle billing and ownership. The reason is simple: external access is the riskiest opening, and the hardest to trace after the fact. External access includes SSH keys for deployment servers, external logins to cloud consoles, admin panels exposed to the public internet, public API keys for third-party services, and any entry point reachable without an internal network or VPN. Once abused, the impact is public and immediate — and even without any ill intent from the departing person, a lost personal device or a stolen account can be exploited through the same opening.

Cutting external access quickly means: revoke and rotate every public-facing key, revoke personal SSH keys and personal access tokens, close or transfer personal accounts on public admin panels, and replace every externally facing webhook secret. Ideally this happens on the day of departure, not after the handover pack is finished. Many people worry that cutting external access first looks distrustful, but the opposite framing is more accurate: it is good for both sides, because it removes in advance the possibility that a later problem gets blamed on the person who left.

Once the outside is clean, take back internal permissions: write access to repositories, edit access to internal documents, admin rights in collaboration tools, deployment rights in CI, read and write accounts for databases. Internal revocation can follow the handover rhythm more slowly, because internal systems usually have logs, approvals, and network isolation, making the risk comparatively contained. Billing and ownership come last: cloud billing admin, payment platform admin, domain ownership, organisation ownership. These changes have large blast radius and are easy to get wrong, so do them once everything else is stable, verifying each change as you go.

One sequencing detail for key rotation: issue the new key first, then revoke the old one, with a short overlap. If you revoke first and issue later, running services break immediately — you have traded a live incident for security. The correct rhythm is: deploy the new key into the service, verify the service works, revoke the old key, and finally verify that the old key really is dead. This "build before you break" rhythm applies to database passwords, API keys, and deployment keys alike.

Step four: audit and review — how to prove it is really clean

Revocation cannot rest on "I think we covered everything". It needs evidence. An audit should check at least four things. First, login records: which systems the departing person's accounts logged into over the past 30 days, whether those logins all predate the departure, and whether there are any anomalous post-departure logins. Second, a leftover-token scan: search code repositories, CI variables, deployment scripts, and documents — by tool or by hand — for hardcoded secrets, expired tokens, and test backdoors. Pay special attention to the "temporary, will remove later" spots: test scripts, example configuration files, old branches, and key fragments pasted into chat history.

Third, a line-by-line review of the permission checklist: every item gets four fields — who handled it, when, how it was verified, and the verification result. Any item without a verification result counts as unfinished. Fourth, an external exposure check: public ports, public storage buckets, public admin panels, public API documentation — confirming that no entry point still hangs off the departing person's personal credentials. Ideally this check is done by the successor rather than the departing person; a fresh pair of eyes catches blind spots more easily.

Keep a written record of the audit in the team's internal documentation: the date, who departed, how many checklist items there were, how many were completed, and what residual risk remains. If some item genuinely cannot be resolved yet — for example, an old vendor that does not support transfer — do not pretend it does not exist. Write the residual risk down, with mitigations and a planned date. Honestly recording a leftover risk is far safer than pretending the list is clean, because a pretended clean list makes everyone relax, while a written risk at least has someone watching it.

The small-team simplified version: when one person wears many hats

The full process above sounds complete, but for a two- or three-person vibe team, copying it wholesale will crush you. So here is a simplified version, built on one principle: keep the critical items, cut the formalities. It protects just four things. First, revoke and rotate all keys and tokens — this is the floor, and not one item can be skipped. Second, transfer ownership of three things: the code repository, the domain, and cloud billing — lose these and the project is gone. Third, leave a one-page handover note covering work in progress, unmerged branches, where secrets live, and contacts — no long document required. Fourth, do one sampled check of login records to confirm there were no anomalous post-departure logins. Everything else can be noted and handled later, but these four must be done within a week of departure.

Small teams where one person wears many hats carry a special risk: the departing person may be simultaneously "the only person who understands deployment" and "the only person with cloud billing access". In that case, the first priority is not documentation but breaking the single point of failure: before they leave, at least two people must be able to deploy independently, log into the cloud console, and handle billing. If a second person genuinely cannot be found, at minimum record the steps on video, write down the recovery procedure, and prepare a backup admin account. One person is a single point of failure; when they leave, that failure becomes a project shutdown.

Another common small-team mistake is substituting a verbal agreement for a system change — for example, everyone agreeing verbally that "you just won't log in anymore" while the account permissions and keys remain untouched. That agreement holds while collaboration is friendly, but it offers no protection if an account is stolen, a device is lost, or a dispute arises later. The rule is simple: permission state is whatever the system shows, not whatever was agreed verbally. Only a change in the system counts as a change in permission.

The usual relapse list: six failures that come back most often

Finally, six relapses to check against during review. First, secrets in CI were forgotten: the key in code was rotated, but the old key still sits in the continuous-integration configuration and is still used at deploy time. Second, a personal access token was never revoked: repository access was removed, but a token generated earlier still works — a back door left open. Third, a shared account's password was never changed: the team shares one admin account, and after departure everyone still knows the password. Fourth, a sub-account in a third-party service was missed: the main account was cleaned up, but a sub-account, API key, or webhook in some third-party service remains. Fifth, local configuration files were ignored: the departing person's machine still holds production configuration files — the team cannot control someone else's computer, but it can rotate every secret those files contained, so the old files become useless. Sixth, the domain and DNS recovery email was never changed: domain control was transferred, but the password-recovery email is still the departing person's personal email — a spare key left behind.

One closing thought on mindset. A good departure handover does not mean a team "distrusts people"; it means a team "does not depend on people". A healthy vibe project should keep running when anyone leaves, and should let anyone who returns to help get back up to speed quickly. Making handover and access revocation a fixed process — rather than something improvised each time — is the mark of a small team growing from "a few people building something together" into "a project that can keep running". The process does not need to be perfect at first. Start with the simplified version in this guide, do it once, review it once, and the next departure will be cleaner than this one.