How would you design least-privilege access for a GitHub organization with dozens of teams and hundreds of repositories?

## Start from how access resolves Every design decision follows from one mechanic: GitHub grants the **maximum** of the applicable permissions — organization base permission, every team grant including those inherited through a parent team, and any direct collaborator grant — with organization owners holding admin everywhere. Nothing subtracts. So least privilege is not achieved by adding restrictive grants; it is achieved by keeping the floor low and making every grant above it visible and removable. ## The floor Set **base permission** to read for a typical engineering organization: people can discover and clone internal code, which is worth a great deal for reuse and incident response, and nobody can push anywhere by default. Where repositories hold regulated or highly sensitive material, either set base permission to none and grant explicitly, or move that code into an organization of its own — **organization boundaries are the strongest isolation GitHub offers**, and a separate org is the honest answer when "nobody else should even see this" is a real requirement. Setting base permission to write is the single most common mistake. It looks like enabling collaboration; what it actually does is guarantee that every joiner can push to every repository, which no access review can ever unwind without changing the setting. ## Grants through teams, always Individual collaborator invitations are the debt that compounds: they are invisible from the team structure and surface only when someone walks repository by repository. Grant to **teams**, and use **nested teams** so that a member of a specialised child team automatically holds the broader parent team's access. Mirror the organization chart closely enough that adding someone to the team that reflects their job is the only access action onboarding requires — and removing them from it is the only one offboarding requires. Most engineers need **Write** and nothing more. Reach for **Maintain** when someone needs repository settings but should not hold deletion, transfer and visibility. Reserve **Admin** for a small owners group, with a documented break-glass procedure so nobody keeps admin permanently "in case". Where the built-in ladder does not fit — a role that needs Write plus one specific capability — **custom repository roles** on Enterprise plans let you compose that instead of over-granting; use them sparingly, because every custom role is another thing a reviewer must understand. ## The people who are not employees **Outside collaborators** — repository access without organization membership — are the right shape for contractors and external partners: base permission does not apply to them and they cannot be placed on teams, so their access is exactly the grants they hold. That precision is also the risk: nothing about them appears on a roster, so they need an explicit expiry and a scheduled review. Restrict who may invite them to owners, so the population is created deliberately. ## Repository lifecycle levers Access design is not only "who can push". Restrict who may **create** repositories (or at least which visibilities members may create), who may **change visibility**, and who may **transfer or delete**. Restrict **forking of private repositories**, because a fork is a copy that leaves your ruleset behind. Each of these is an organization setting and each closes a route by which content or permissions escape the model you designed. ## Machines Never build automation on a named human's long-lived token; it carries their whole reach and dies when they leave. Prefer **GitHub App installation tokens** — short-lived, scoped to selected repositories and permissions — for anything that touches the API; **fine-grained tokens** with expiry where an app is disproportionate; **read-only deploy keys** for a machine that clones exactly one repository. Inside GitHub Actions the run's own `GITHUB_TOKEN` already covers the workflow's repository. ## Making it stick Enforce **2FA** for the organization and, where available, SSO so identity is centrally revocable — the fastest offboarding is the one that happens in the identity provider. Manage the structure **declaratively** (an infrastructure-as-code provider or the organization API) so team and grant changes are reviewed like code and drift is visible. Then run periodic access reviews driven by data rather than memory: enumerate collaborators and their `role_name` per repository, list outside collaborators, list repository deploy keys, and diff against what the declared model says should exist. The audit log answers "who granted this and when". ## The tradeoff to say out loud Every restriction has a friction cost, and a model so tight that people route around it with shared accounts is worse than a looser one they follow. The judgment is picking where precision is worth it — production deployment paths, credential-bearing repositories, anything regulated — and accepting read-level openness elsewhere so the organization keeps its ability to find and reuse code.