Give most contractor developers the Write role on a single repository, and nothing higher. Use Read for reviewers and auditors, Triage for people who only manage issues, and avoid Maintain and Admin. Admin can change security settings and delete the repository, which a fixed term engagement almost never needs.
The five roles in plain words
GitHub lists the organization repository roles from least to most access. Here is each one with what GitHub recommends it for and what that means for a contractor.
| Role | GitHub's recommended use | Contractor fit |
|---|---|---|
| Read | Non-code contributors who want to view or discuss | Auditors, designers, product reviewers |
| Triage | Manage issues, discussions and pull requests without write access | QA or project coordinators |
| Write | Contributors who actively push to your project | Developers on the engagement |
| Maintain | Project managers who manage the repo without sensitive or destructive actions | Rare, long engagements only |
| Admin | Full access, including managing security or deleting a repository | Not for contractors |
Decide by the task, not the title
Ask what the person must do on day one, then pick the role that allows exactly that.
- A developer who pushes branches and opens pull requests needs Write.
- A QA engineer who files and labels issues needs Triage.
- A security reviewer who reads code and comments needs Read.
- A delivery manager who watches progress needs Read, plus access to your tracker rather than your code.
If you find yourself reaching for Maintain because the contractor needs one specific extra permission, check whether a custom repository role fits. GitHub supports custom roles on some plans, so you can add a single permission to a lower role instead of jumping a whole level.
Write is more powerful than it sounds
Write access is not harmless. GitHub's guidance on Actions notes that any user with write access to a repository has read access to all secrets configured in that repository. That is a strong reason to keep deployment secrets in environments with required reviewers rather than repository level secrets, and to read protecting deployment secrets from contractors.
Write also lets a person push branches directly unless a branch rule says otherwise. Without protection, a contractor with Write on the default branch can push straight to it. Require pull request reviews so that, in GitHub's words, collaborators can only push changes to a protected branch through a pull request approved by the required reviewers.
A five minute role review
- List every contractor account and its repository role.
- Flag every Maintain or Admin grant and ask who approved it.
- Check whether any contractor holds access through a team or a former team rather than a direct grant.
- Confirm the role matches the current task, since roles tend to stay at the level of the busiest week.
- Record the end date for each grant.
Why admins are the real risk
Admin is where small mistakes become large. An admin can change branch protection, add deploy keys, invite more collaborators, and remove the review requirement your auditors rely on. If someone on the contractor side truly needs Admin for a short task, grant it for the task and drop it after, and note both events in your tracker.
For the wider process, see the contractor offboarding checklist and branch protection rules worth enabling.
Safeguard's policies and gates can add automated checks on pull requests from any role, and its asset discovery helps you find repositories that contractors can reach. Try the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the gate and notice that the checks apply to the pull request, not to the person who opened it.
Quick check
Is Write enough for a contractor developer?
Usually yes. Write lets them push branches and open pull requests, and branch rules then control what reaches your protected branches.
Can a contractor see repository secrets with Write access?
GitHub documents that anyone with write access to a repository has read access to the secrets configured in it, so keep high value secrets in protected environments.
Sources
- Repository roles for an organization
- Secure use reference for GitHub Actions
- About protected branches
Last reviewed: 19 October 2026.
