Onboarding New Developers Without Full Codebase Access

Why onboard with less than everything

Most teams add a new hire to the GitHub organization on day one with the same access as everyone else. That's simple, and for many teams it's fine. The reasons to do it differently:

• Probation is real. Some new hires don't work out in the first months, and some leave for a competitor. Whatever they cloned stays with them.
• Core IP is concentrated. The code that differentiates a company (models, pricing, matching, detection logic) is usually a small fraction of the repository. A new frontend engineer doesn't need it in week one.
• Their AI agents inherit their access. A new hire running a coding agent on day one gives that agent everything they can read, including whatever a prompt injection can reach.
• Less noise. A focused working copy is easier to learn than a large monorepo.

The cost of doing it badly is real too: if a restricted new hire can't build, can't run tests, or waits days for access, you've lost the productivity you hired for. Any approach has to keep the build working.

What least privilege looks like for a new developer

A reasonable day-one shape:

Then expand on a schedule: after a first project, at the end of probation, when they join on-call.

Options on GitHub

Everything, with merge controls

Add them to the repository and rely on CODEOWNERS and branch protection to require reviews from owners on sensitive paths. This controls what they can merge, not what they can read. See CODEOWNERS is not access control.

Repository-per-area

If your code is already split across repositories, onboarding with least privilege is mostly team membership: add the new hire to the GitHub teams for the repositories they need. GitHub's repository roles are per repository, so this is fully native.

The catch is that in a monorepo, or when the sensitive code lives in the same repository as everything else, there's nothing to scope. Splitting a monorepo for onboarding alone is rarely worth it; see monorepo permissions.

Sparse checkout

Telling new hires to use git sparse-checkout keeps their working tree small, but every object is still in their clone. Fine for focus, not for restriction. Details in Git sparse checkout vs real access control.

Filtered views

Serve the new hire a version of the repository with some paths removed or reduced to interfaces, and route their changes back as normal pull requests. That's what Gitfence does, described below.

The rest of a least-privilege onboarding

Code access is one part. The other parts are usually easier:

• Agreements first. Employment contracts usually cover confidentiality and IP, but make sure they're signed before access, and add any AI-tool policy you have. See NDAs for developers before code access.
• No standing production access. Use staging environments with masked data for the first weeks.
• Expiring credentials. Tokens and keys with expiry dates. Avoid long-lived personal access tokens for automation.
• Secrets outside the repo. If secrets are in the repository, every new hire receives them. Move them to a secrets manager before thinking about folder permissions.
• A request path. Make it easy to ask for more access, with a reason, and quick to approve. Restrictions that take a week to lift get worked around.
• Scheduled reviews. Look at access at the end of probation and when someone changes teams.

How Gitfence handles onboarding

Gitfence sits in front of GitHub and gives each restricted person and AI agent their own view of a repository. Full-access teammates keep working in GitHub with nothing changed and aren't billed.

For a new hire:

1. Invite. Create an invitation link for a repository and group (for example, "New hire: web"). Invitations can be limited to a specific GitHub login or email domain, a number of uses and an expiry.
2. Sign. If the repository or group requires documents (an NDA, an acceptable-use policy), the new hire signs them before any code is available. Each signature records the document version and content hash, typed name, time and IP address.
3. Clone. They clone a Gitfence URL with plain git. Their view contains only what their group allows: per folder or file, No access, Types only, Can read or Can edit. Types only gives generated TypeScript declarations with literal values redacted, so code that calls a hidden module still type-checks.
4. Work. Their pushes are validated against their permissions and arrive in GitHub as normal pull requests, reviewed like anyone else's. Fenced CI runs the full test suite on the real code in a no-network sandbox and redacts hidden source from output.
5. Expand. When they need more, they (or their AI agent) request access to a path with a reason. An admin approves it, and their view gains the files with a new commit; nobody re-clones or force-pulls. You can also grant individual exceptions to a group's rules, or move them to a broader group at the end of probation.

The AGENTS.md and CLAUDE.md guide injected into each view tells their AI agents what's fenced and how to run tests or request access, which also helps the person.

Limits

• Moving someone to wider access is instant; narrowing later only affects what they can fetch from then on. If you're unsure, start narrow.
• Commits that touch both hidden and visible files keep their messages, so new hires may see commit messages about code they can't see.
• GitHub only today; Types only supports TypeScript.
• Temporary access ("this folder for a week"), Slack approvals and ticket-scoped access tied to Linear or Jira are available; the Slack, Linear and Jira connections are tested offline, not yet against the live services.

See Gitfence for onboarding and pricing.

A day-one checklist

1. Signed employment agreement, NDA and AI-tool policy on file.
2. Access to the repositories or paths for their first project, plus interfaces for what they call.
3. No secrets in what they can clone.
4. Staging access with masked data; no production.
5. Personal, expiring tokens for any automation or AI agents.
6. A documented way to request more access.
7. A calendar reminder to review access at the end of probation.

FAQ

Should new developers get access to the whole codebase on day one?

Not necessarily. They need enough to do their first projects and to build and test. Core IP, infrastructure and secrets can usually wait.

Won't restricted access slow down onboarding?

It can if they can't build or run tests. Use interfaces for code they call and run tests somewhere that has the full code, and keep requests for more access quick to approve.

How do I give a new hire read-only access to a GitHub repository?

Add them to the repository or a team with the Read role. Note that Read covers the whole repository; it can't be limited to some folders on GitHub.

What should be off-limits for a new developer?

Typically secrets, infrastructure and deployment configuration, production data, and the few modules that are your core IP. Everything else depends on their role.

When should we expand a new hire's access?

Common points are after their first shipped project, at the end of probation, and when they take on on-call. Expand earlier if restrictions are blocking real work.