Who should be allowed to invite outside collaborators to your repos?

By default, anyone with admin access to a repository can invite outside collaborators to it. On organizations whose plan supports the restriction, you can limit that power to organization owners. Either way, route every outside invitation through a request that names the person, the repository, the role and the end date.

What the default allows

GitHub's documentation says people with admin access to a repository can add an outside collaborator to the repository, choosing the level of access for each. It also says the default is that anyone with admin access to a repository can invite outside collaborators, and that you can restrict this to organization owners only.

That default means the number of people who can bring an outsider into your code equals the number of repository admins. In many organizations, that is dozens of people across hundreds of repositories, none of whom coordinate.

What the restriction does

The setting is in your organization settings. You deselect the option that allows repository administrators to invite outside collaborators, and only owners can invite. Two limits apply, both from GitHub's page:

• Only organizations on plans that support it can restrict invitations to owners. Check your plan before planning around the setting.
• If your organization belongs to an enterprise, an enterprise policy may already decide this and can block you from changing it.

If you cannot use the restriction, compensate with process and detection (see below).

Why it matters for contractors

Outside collaborators can count toward paid licenses on private repositories, and removing one does not automatically reduce the paid license count. That is mainly a cost matter, but it is also a signal: if the seat count rises without a matching ticket, someone invited an outsider without telling you.

More important, a collaborator invited by a repository admin may get Write on a repository holding secrets or customer logic, with no security review. The invitation is the front door, so put a person at it.

An intake process in five steps

1. Request. The sponsoring staff member submits the person's GitHub username, the repository, the role, the reason and the end date.
2. Check. An owner confirms there is a signed agreement, that the person will use two-factor authentication, and that the role is the lowest that fits. See which role a contractor should get.
3. Invite. An owner adds the person to the one repository.
4. Record. The grant, the approver and the end date go into the access register.
5. Review. Calendar a check a few days before the end date.

Detection if you cannot restrict

• Review the list of outside collaborators monthly and match each to a request.
• Search the organization audit log for collaborator additions. GitHub keeps the last 180 days of events, so a monthly look covers the window comfortably. See the audit log review post.
• Limit the Admin role so fewer people hold the power to invite.

Who counts as an approver

Pick people who understand data sensitivity, not only who has the time. A rotating pair of owners reduces the chance of a single point of failure. Write down the backup when the main approver is on leave, or requests will go around the process.

Related: member or outside collaborator and contractor access never expires.

Safeguard's asset discovery can help you build an inventory of repositories and accounts to compare against your register, and its compliance and evidence automation can keep the review record. Start with the free scan.

Quick check

Sources

• Adding outside collaborators to repositories in your organization
• Setting permissions for adding outside collaborators
• Removing an outside collaborator from an organization repository
• Reviewing the audit log for your organization

Last reviewed: 19 October 2026.