How do you set strict base permissions for repositories in a GitHub organisation?

What “base permissions” should mean in a GitHub organisation

Strict base permissions are the organisation-wide default that applies before anyone asks for extra access. The practical goal is to make the default useful enough for collaboration, but narrow enough that a new member or new repository does not inherit broad read or write access by accident. In GitHub, the safest approach is to treat the default as a floor, not a convenience setting.

That means choosing the least permissive organisation-level baseline that still supports day-to-day work, then using repo-level exceptions for the small set of teams that genuinely need more. If you need to compare permission models or decide whether a broader role should exist at all, the Authorisation Models Guide is useful because repository access is really an authorization design problem, not just an admin setting.

For GitHub environments that also depend on automation, tokens, or other non-human access paths, the same principle applies to machine access as well as people access. The GitHub and GitHub Actions Security Guide is relevant here because base permissions and workflow permissions should line up, otherwise repository defaults can be undermined by overly broad automation access.

How to apply the setting without creating hidden access

Start by reviewing the organisation’s current default repository permission and the repository creation path. The important question is not only “what is the default?” but “what happens when a new repository is created, transferred, or inherited by a team?” A strict setup checks all three states, because drift often appears when one repository gets a special grant and that exception quietly becomes the norm.

Then verify who can change repository access, who can create repositories, and whether inherited team access matches the intended model. If a team needs broad access across many repositories, it should be explicit and limited to that team’s scope, not provided indirectly by a generous organisation default. The Authorisation Models Guide is a good reference point for deciding when role-based assignment is enough and when a more granular policy model is needed.

Also review whether repository settings, inherited team permissions, and workflow-related tokens are aligned. If a repository is meant to be protected by limited human access, but CI workflows or shared service identities can still reach sensitive content, the effective permission boundary is weaker than it looks on paper. The GitHub and GitHub Actions Security Guide helps connect those controls so the default does not get bypassed through automation.

What to check after tightening the default

After you change the base setting, validate the repositories that already exist, not just the new default. Existing repositories may retain broader access, and older team assignments can leave members with more visibility than the organisation policy now intends. That is why strict base permissions should always be paired with a repository-by-repository access review.

You should also check whether private repository access is still appropriate for every team that currently has it. In many organisations, the biggest weakness is not the default itself, but the buildup of exceptions over time. The operational test is simple: if a team cannot explain why it needs access to a repository, that access should not remain by default.

For organisations that use GitHub extensively for software delivery, pairing this review with workflow hardening is usually the most efficient next step. The GitHub and GitHub Actions Security Guide is especially useful when you need to confirm that repository permissions, token scope, and workflow permissions do not accidentally create a wider blast radius than intended.

Risk and Threat Considerations

Overly broad base permissions create organisation-wide exposure because every new repository starts with more access than it needs. That increases the chance of accidental disclosure, unauthorized edits, and privilege creep, especially when teams assume the default is “safe enough” and stop reviewing inherited access.

Failure mechanism: A permissive default, combined with inherited team access and unreviewed exceptions, expands read or write reach across repositories faster than administrators notice.

Impact: Sensitive source code, configuration, or operational material can become visible or editable to more users than intended, and that broader exposure can persist until someone performs a deliberate access review.

Practitioner Guidance

What to verify: Confirm the default repository permission, then test what a new member, a new repository, and an inherited team assignment actually receive in practice. The setting is not strict unless all three paths produce the intended least-access outcome.

Common mistake: Treating the organisation default as a one-time admin choice instead of a living control. In GitHub, access often drifts through team inheritance, repo exceptions, and automation permissions, so the baseline must be reviewed after structural changes.

Practitioner takeaway: The strongest GitHub permission model is the one that makes broad access explicit, reviewable, and rare, rather than something that appears automatically whenever a repository is created.

Related resources from NHI Mgmt Group

• How should organisations stop auto-sync from turning desktops into repositories of credentials?
• What happens when organisation-wide GitHub permissions are too broad for developer workflows?
• How should security teams reduce repo hijacking risk when GitHub organisation names or repositories change?
• Why do overly permissive GitHub Actions permissions increase supply chain risk in repositories that use custom actions?