When a subcontractor's engagement ends, most agencies do the same thing: remove them from the GitHub organization, remove them from Slack, and close the ticket. That ends their logins. It does not end their access, because everything they could read while they were on the project is still valid, and some of it is sitting in a repository they cloned onto their own laptop.
GitGuardian's State of Secrets Sprawl 2026 report, which analyses 2025 data, found that 32.2% of internal repositories contain at least one hardcoded secret, against 5.6% of public ones. And the secrets don't expire on their own. This post is the offboarding checklist that follows from those two facts, written for the owner of a small agency who has to answer to a client if a credential from a finished project turns up somewhere it shouldn't.
What does removing a subcontractor from GitHub actually do?
Less than it feels like. GitHub's documentation on removing an outside collaborator says removal ends their access to the repository and deletes their forks of private repositories. It also says, in as many words, that "the person will still retain any local clones of your repository." GitHub puts the responsibility for getting confidential material deleted on you, not on the platform.
So the clone on the subcontractor's machine is a full copy of the repository history as of their last pull. Whatever was committed in that history, including the config file somebody fixed three months ago, is theirs to keep unless you have made it worthless. You cannot take a clone back. You can only make what is in it stop working.
Why does the repository matter more than the login?
Because of where secrets live. GitGuardian's 2026 report states that internal repositories are about six times more likely than public ones to hold a hardcoded secret, 32.2% against 5.6%. The reasoning is easy to reconstruct from the reader's side: a private client repo feels safe, so a developer under deadline pastes the staging database URL straight into a config file and moves on. Nobody scans it because nobody expects to publish it.
That describes the typical overflow project. A client's repository is private, the agency's engineers are rushing, and a subcontractor joins halfway through to help. Picture a 15-person agency that brings a three-engineer subcontractor team into a client's Next.js and Postgres build for a ten-week push. By week four the repo has an environment file template, a Stripe test key in a seed script, and a CI config that references a cloud provider token. None of it is negligent by the team's standards. All of it is readable by every person with clone access, and a clone is forever.
How long do leaked secrets stay valid?
Longer than people assume, and the trend runs the wrong way. GitGuardian's report states that 64% of the valid secrets it detected in 2022 were still active and exploitable four years later. Its yearly chart shows the share of still-valid secrets at 64% for the 2022 cohort, 66% for 2023, 70% for 2024 and 77% for 2025. The page does not give a time-to-rotation in days, so this post doesn't invent one.
The plain reading is that nobody rotates. A key that was never revoked will keep working until someone is made to. When a subcontractor leaves, the clock on that key starts at the day you stop paying attention, and the report suggests it may not stop for years.
Which access survives the offboarding?
This is the part worth a written list, because the items are scattered across systems and nobody owns all of them. The ones that outlive a removed collaborator:
- Deploy keys. GitHub's deploy key documentation says a deploy key "will still be active as it isn't tied to the specific user, but rather to the repository." It also notes that deploy keys are read-only by default but can be given write access, in which case they can act like an organization member with admin access. If the subcontractor set one up for a server or a CI job, deleting the person does nothing to it.
- Personal access tokens and CI variables. Any token the subcontractor generated and stored in a pipeline setting keeps working as long as the account that issued it exists, and that account may not be yours.
- Cloud and database credentials. Anything pasted into an environment file, a seed script or a shared password manager entry.
- Third-party service keys. Payment, email, analytics and error-tracking keys the app calls.
- Shared accounts. Staging admin logins, DNS and registrar access, app store developer accounts.
- The history. Deleting a secret from the latest commit leaves it in every earlier commit, and in every clone.
Verizon's 2026 Data Breach Investigations Report, published 19 May 2026 and built on 2025 incident data, put breaches involving a third party at 48% of all breaches and said third-party involvement was up 60%. Verizon's summary is about suppliers in general, not about agency subcontractors, and it doesn't break out access left behind after a project ends. It is still the right backdrop for why a client's security questionnaire now asks how you handle exactly this.
What should the rotation checklist look like?
Run it in this order, on the day the engagement ends and not the following sprint.
- 1.List every system the subcontractor touched. Use the project's access log or the engineer's own handoff note, not your memory of who set up what.
- 2.Rotate first, remove second. If you remove the person and then rotate, the secrets are exposed for however long the rotation takes. Rotating first closes the window while they still have an account you can monitor. It does not matter that they probably won't misuse anything; the point is that you can state you didn't leave it to chance.
- 3.Replace deploy keys and tokens. Delete each deploy key and issue a new one. GitHub's own guidance for finer control is to use a GitHub App rather than a long-lived deploy key, which also means access follows the app and not a person.
- 4.Search the history, not just the current tree. A secret scanner pointed at the full commit history will find the key that was removed from the file last month. Rotate anything it finds even if the line is gone.
- 5.Revoke at the provider, not in the repo. Removing a key from the code does nothing. The key has to be disabled where it was issued.
- 6.Record it. A one-page note listing what was rotated, when and by whom is what you hand a client who asks, and what lets you answer a security questionnaire without guessing.
- 7.Collect the confirmation of deletion. Ask the subcontractor to confirm in writing that local clones are deleted, and make sure your subcontract required it. This is a contractual comfort, not a technical control, and you should treat it that way.
The subcontract itself should have required most of this from the start. Our write-up on subcontractor contract flow-down covers the data-protection terms that should travel with the work, and the post on who owns code a subcontractor writes covers the ownership paperwork that sits alongside it.
When is this checklist the wrong answer?
If the repository holds nothing but a static marketing site, or the secrets in it are all short-lived and issued per developer, a full rotation is more ceremony than the risk deserves, and a one-line check is enough. The same goes for work where the client's own security team already controls every credential and your people only ever touched a sandbox.
The checklist also cannot fix a bigger design problem. If a subcontractor needed a production database password in the first place, the fix is not a better offboarding step. It is a setup where production secrets never reach the people doing overflow work. That is a decision to make at the start of the engagement. For how we work with agencies as an overflow bench, see our overview for agencies.
Pick the last subcontractor engagement you closed and run steps one to six against it as an exercise. If you can't list every system they touched in ten minutes, that is the gap. Then add a rotation line to your subcontract template and your project close-out checklist so it stops depending on whoever remembers. If you'd like to talk through how access is scoped when we work as the overflow bench for an agency, get in touch with the stack and the clients' security requirements and we'll say plainly whether it fits.
