Not by default. GitHub's documentation says restrictions in a branch protection rule do not apply to people with admin permissions, or to custom roles with the bypass permission, unless you opt in. For audit evidence, either enforce the rules on admins or keep a short, reviewed list of who can bypass and why.
Why auditors ask about bypass
A control that says "all production changes get a second reviewer" has an exception if one person can merge alone. Auditors sample merges and then ask whether the control could be skipped. The bypass list is the honest answer to that question, so know it before they do.
What the documentation says
On protected branches, GitHub documents these points:
- Each rule disables force pushes and branch deletion by default.
- Rule restrictions do not apply to admins or to roles with the "bypass branch protections" permission.
- You can optionally apply the restrictions to administrators too, and there is a setting named "Do not allow bypassing the above settings".
- Actors can be added to bypass lists only when the repository belongs to an organization.
Rulesets are the newer mechanism. A ruleset is a named list of rules for branches or tags. When you create one you can allow certain users to bypass it: a role such as repository administrator, specific teams or GitHub Apps. A repository can have up to 75 rulesets, and organization-wide rulesets also support up to 75.
Two ways to be audit ready
| Approach | What you show | Risk |
|---|---|---|
| No bypass for anyone | Setting screenshot or API output plus a note on a break-glass process | Emergencies need a documented path |
| Small bypass list | The list, a reason per entry, and a review date | List drifts if never reviewed |
Both can pass. An unexplained admin who can merge alone cannot.
Steps
- Open the protection rule or ruleset for your production branch.
- Check whether admins are bound. If not, note it.
- Read the bypass list. For each entry write one sentence on why it exists.
- Decide whether a bypass should exist at all. Many small teams find "do not allow bypassing" workable once a break-glass process is written.
- Pull the settings through the REST API on a schedule so you have dated copies. The REST docs list a branch protection endpoint at the repository, branch and protection path, and a rulesets endpoint at the repository and rulesets path.
- Keep a note whenever a bypass is actually used, with the pull request link.
For a related angle on approvals, see branch protection evidence for code integrity reviews.
Try it yourself
Click through it at your own pace, or open it full screen. Check what the gate blocks and which result is recorded on the pull request.
Where Safeguard fits
Safeguard provides policies, gates and guardrails for pull requests and compliance and evidence automation, so a blocked merge leaves a record. Try the free scan for the dependency side.
Quick check
Are admins blocked by default under branch protection?
No. The documentation says the restrictions do not apply to admins or bypass roles unless you apply them to administrators too.
Do rulesets also have bypass?
Yes. You can allow roles, teams or GitHub Apps to bypass a ruleset, so review that list.
Sources
- GitHub Docs: about protected branches
- GitHub Docs: about rulesets
- GitHub Docs: REST API for branch protection
Last reviewed: 19 October 2026.
