Outside collaborators and base permissions in a GitHub organization

An outside collaborator is someone who is not an organization member but can reach one or more of its repositories. The organization's base permission does not apply to them, so they get exactly what you grant per repository. That makes them a good fit for contractors, if you review them.

What base permissions do

The base permission sets a baseline for all organization members across the organization's repositories. A higher access level granted on a specific repository overrides it. Changes apply to new and existing members. By GitHub's documentation, members have read access to public repositories by default, and internal repositories give at least read access even if the base is none. Changing the base does not automatically update permissions on private forks.

For least privilege, set the base low and add team access where needed.

What outside collaborators are

GitHub describes an outside collaborator as a non-member with access to one or more repositories, at a level the organization sets. Key points:

• Base permissions do not apply to them.
• They cannot be added to a team, since team membership is limited to organization members.
• To reach a fork of a repository, they must be added to that fork separately.
• If the organization requires two-factor authentication, outside collaborators must enable it before accepting an invitation.
• On paid plans, an outside collaborator on a private repository uses a paid license.

A least privilege setup for contractors

1. Add the contractor as an outside collaborator on only the repositories they need.
2. Give the lowest role that does the job.
3. Record an end date and an owner for each one.
4. Require two-factor authentication at the organization level.
5. Remove access the day the contract ends.

Review them on a schedule

Outside collaborators are easy to forget, because they appear on repository settings pages, not in team lists. Export the list of outside collaborators every quarter and ask each repository owner to confirm. Also review stale invitations.

How it links to audits

Auditors ask who has access to source code and how it is approved and removed. A dated review of members, teams and outside collaborators is strong evidence. Read access review evidence: what auditors look for.

Keep one eye on private forks. GitHub notes that changing base permissions does not automatically update the permissions of private forks, so a fork created under an old, broader setting may keep broader access than you intended. After you lower the base permission, list private forks and check their access individually, and ask collaborators who need a fork to be added there on purpose, as the documentation describes.

Quick check

Safeguard compliance and evidence automation can help you collect access review evidence on a schedule.

Sources

• Setting base permissions for an organization, GitHub Docs
• Adding outside collaborators to repositories in your organization, GitHub Docs

Last reviewed: 19 October 2026.