In Azure DevOps, anyone granted "Bypass policies when completing pull requests" or "Bypass policies when pushing" can skip your branch policies. The first lets them complete a pull request that fails policy. The second lets them push straight to a protected branch. Review who holds either permission, and scope it to a single branch where possible.
What the two permissions do
Branch policies only protect a branch for people who do not hold a bypass permission. Microsoft's documentation describes two separate permissions.
| Permission | What it allows | Where it applies |
|---|---|---|
| Bypass policies when completing pull requests | Complete a pull request even if it does not satisfy policies | Pull request completion only |
| Bypass policies when pushing | Push directly to a protected branch without meeting policy | Pushes from local repositories and web edits |
You can grant either permission to a user or group, and scope it to a whole project, one repository, or a single branch. The documentation also warns to be careful with repository and project level grants.
Why a bypass is easy to miss
Two details trip teams up.
First, policy status still shows up for people who can bypass. The documentation says the reported status is advisory for them. If a person with bypass rights approves, a failed policy does not block completion. So a pull request can look red and still merge.
Second, a required policy blocks direct pushes only for people without a bypass permission. If a group such as Project Administrators holds the push bypass, your "everything goes through review" rule has a hole for that group.
How to audit it
- Open the repository security page for the protected branch and list every user and group with either bypass permission set to Allow.
- Check inherited permissions as well as explicit ones. A group at project level can grant bypass on every repository below it.
- Remove bypass from broad groups. Keep it for a small named group, ideally one that is empty until needed.
- Re-scope any remaining grant from project to repository, or from repository to the single branch it is needed on.
- Turn on the organization audit log if your organization is backed by Microsoft Entra ID. Microsoft lists branch policy changes among the events it records.
A safer pattern for emergencies
Hotfixes are the usual reason a bypass exists. Rather than a permanent grant, keep a break glass group with no members. Add a named person, record why, complete the change, and remove them. The audit log then shows the membership change and your records show the reason.
Pair this with a build validation policy marked Required and a minimum reviewer policy, so that the normal path is the easy path. People bypass policies mostly when the policies are slow or flaky.
Try it yourself
Open the demo below and click through the pull request gate. Watch which findings stop a merge and which only warn, then ask which of your own branches would let a bypass skip that step.
Click through it at your own pace, or open it full screen.
Quick check
Does a bypass permission turn off the policy?
No. Policies are still evaluated and shown on the pull request. For someone with bypass rights the status is advisory, so a failing policy does not block completion.
Is bypass when pushing the same as bypass when completing pull requests?
No. The push permission covers direct pushes and web edits to a protected branch. The completion permission covers only finishing a pull request that fails policy.
Can I scope a bypass to one branch?
Yes. Microsoft's documentation says bypass permissions can be scoped to a project, a repository, or a single branch.
Safeguard policies and gates can add a second, independent check on pull requests, and you can try a free scan at gold.safeguard.sh/scan. Treat any platform level bypass as something to review on a schedule.
Sources
- Set and manage branch policies, Microsoft Learn
- Access, export, and filter audit logs, Microsoft Learn
Last reviewed: 19 October 2026.
