Restrict bypass policies in Azure DevOps properly by granting the permissions “Bypass policies when completing pull requests” and “Bypass policies when pushing” only to a small, named group of administrators. Keep ordinary maintainers, build identities and service accounts out of this unless there is a clearly defined exceptional case. That way, branch policies remain the standard and bypass remains the rare exception.
This is the proper baseline setting for protected branches. Branch policies are the rules that must be met before a merge or push can go ahead.
In its security baseline for main branches, Microsoft recommends restricting both bypass permissions to a small admin group. Microsoft also lists at least two reviewers, linked work items, build validation and comment resolution as sensible defaults, among other things (Microsoft Learn, “Securely use Git repos and pull requests in Azure Repos”, accessed on 01.11.2026).
In practice, that means:
- do not treat bypass as a more convenient route through the rules
- define exceptions in advance and assign clear responsibility for them
- review highly privileged rights regularly
If bypass is granted broadly, your branch policies lose their effect at the permission level alone.
The two bypass permissions
You should consider these two permissions separately. “Bypass policies when completing pull requests” allows a pull request to be completed even though required policies have not yet been satisfied. “Bypass policies when pushing”, by contrast, allows a direct push to a branch despite the policies that apply there. This distinction matters operationally, because completing a pull request and pushing directly are two different control paths.
What can be bypassed is broader than it often appears in day-to-day work. Branch policies in Azure Repos include, among other things:
- a minimum number of reviewers
- linked work items
- comment resolution
- permitted merge types
- build validation
- status checks
- automatically included reviewers
All of these policies are switched off by default (Microsoft Learn, “Branch policies and settings” and “Branch policies overview”, accessed on 01.11.2026).
So bypass is not a minor shortcut, but a way around the intended protection model. Anyone with these permissions can override controls that are otherwise meant to apply to all changes.
A common mistake in organisations is this: clean, strict policies are defined, but project administrators, release identities or experienced developers are also given broad bypass rights. Security then shifts away from auditable rules and back towards individual judgement calls.
If you would like a quick refresher on the individual policies, you will find a compact overview in our article on Branch Policies in Azure DevOps.
Who should have these permissions – and who ideally should not
In practice, the rule is: keep the circle as small as possible. This means specifically identified people in platform, DevOps or repository administration who are explicitly responsible for exceptions. The benchmark is not the size of the team, but the number of people who actually need to decide on and take responsibility for such exceptions.
Ordinary maintainers generally do not need these permissions. For the usual change path, pull requests with the existing policies are enough. If a team needs bypass regularly, that usually points to a process or policy problem rather than a permissions problem.
Build and automation identities deserve particularly strict scrutiny. Service accounts should receive these permissions only if a specific, documented exceptional case cannot be solved technically in another way. Otherwise, emergency rights that were meant to be rare quietly become permanent privileges.
This is important too: do not automatically assign both bypass permissions together. Someone who may complete a pull request in exceptional cases does not necessarily also need to be allowed to push directly to the protected branch. In many environments, direct push is the stronger permission because it bypasses the pull request path altogether.
As a counterweight, your normal branch policies should deliberately remain strong. For main, Microsoft recommends at least two reviewers, automatically included reviewers for sensitive paths, linked work items, build validation and comment resolution, among other things; bypass is expressly not intended to be the normal route around these controls (Microsoft Learn, “Securely use Git repos and pull requests in Azure Repos”, accessed on 01.11.2026). If you want to structure roles and permissions around pushing, merging and bypassing rules more systematically, you will find a suitable overview in our article on Roles and permissions in Azure Repos.
One more technical detail for context: “Limit merge types” controls history, but it is not a direct security control. Squash creates a more compact target history, but combines the source commits. If your audit model depends on the exact sequence of commits, Microsoft describes merge-commit strategies as more suitable (Microsoft Learn, “Securely use Git repos and pull requests in Azure Repos”, accessed on 01.11.2026).
Emergency changes without lasting damage
Treat the exceptional case as a procedure, not as a spontaneous one-off action. Define in advance who decides, in which situations bypass is permitted, how the reason is documented and who is responsible for the follow-up review. Under pressure, a clear process helps more than a broadly defined special permission.
For urgent changes, a bypassed pull request is usually easier to trace than a direct push. Discussion, diffs and status are then brought together in one place. That is not something specific to Azure DevOps, but general Git and review practice.
Returning to the normal state matters too. After an exception, you should
- fix the actual cause,
- remove any temporarily granted permissions,
- carry out the checks that were skipped,
- and evaluate the incident as input for learning in your policies or operating procedures.
How robust your standard process remains under time pressure also depends on the reviewer settings. In the reviewer policy there are options, among others, for requester self-approval, blocking approval by the most recent pusher, allowing completion despite “wait” or “reject”, and resetting votes after new pushes. These switches affect how easily a process softens under stress or remains stable (Microsoft Learn, “Branch policies and settings for Git repositories in Azure Repos”, accessed on 01.11.2026).
Useful in operations: policies can also be set via “az repos policy” commands or the REST API. That makes standardised restoration and consistent project settings easier when you want to roll back exceptions cleanly (Microsoft Learn, “Branch policies and settings for Git repositories in Azure Repos”, accessed on 01.11.2026).
If you would rather safeguard exceptions through additional machine-readable signals than through broader permissions, that is often the more suitable next step.
Reviewing and tracking bypass properly
Do not review bypass only as a permission, but also as an exceptional event. What matters is whether a case can later be reconstructed cleanly from the repository, the pull request and the permission state. That helps internally when questions arise and stops exceptions from turning into hidden normal practice.
A fixed review view at two levels is useful:
- Assignment: Who has “Bypass policies when completing pull requests” and who has “Bypass policies when pushing”?
- Use: In which specific cases was the standard path left?
- Justification: Is the reason clearly recorded in the item itself?
- Follow-up work: Were the skipped controls carried out afterwards, or was the root problem fixed?
Especially with protected branches, the second question is often more revealing than the first. Even a small admin group can still act too broadly if exceptions are not visibly justified.
It is also helpful to distinguish between policy types. “Limit merge types” mainly controls commit history and is not a direct security control; Microsoft classifies this setting accordingly (Microsoft Learn, “Securely use Git repos and pull requests in Azure Repos”, accessed on 01.11.2026). For tracking, that means merge types do not explain why reviewer, build or status requirements were bypassed.
If you want to tighten the normal path on sensitive paths, automatically included reviewers are often the more suitable lever than additional special permissions.
For AI-supported reviews, you should also assess the audit trail soberly. According to Microsoft Learn, “Review pull requests” and “Use Copilot code reviews in Azure Repos”, accessed on 01.11.2026, the function leaves only a Comment Review. It therefore does not satisfy a required-reviewer policy and does not block a merge. For data protection, DORA, NIS2 and co-determination, what matters is the specific processing and the context of use; review this with legal counsel or data protection officers.
Common operational questions
How do you check whether bypass is really remaining the exception?
It is not only the permission that matters, but the pattern. If the same teams, repositories or times keep appearing, that is often no longer an isolated case, but an operational problem. So look regularly at three points:
- who has the permission,
- who actually uses it,
- and whether the reason is clearly recorded in the item.
For later follow-up questions, it is important that the decision, the trigger and the affected branch remain traceable together.
What matters when assessing preview and AI features?
Separate functional benefit, audit trail and data processing. Microsoft classifies preview features as subject to change; they have no SLA and may change (Microsoft Learn, “Use Copilot code reviews in Azure Repos”, accessed on 01.11.2026). Whether a comment is created, whether a merge is blocked, or whether data is processed outside the data residency of your Azure DevOps organisation are different questions. You should check the current position on security and data aspects on the security and data page.
What else should you pay attention to in internal requirements?
With data protection, DORA, NIS2 and co-determination, the issue is not only the repository, but also roles, evaluation and behavioural relevance. Clarify such questions with legal counsel or data protection officers, not through a tool setting. Product status changes; for that, a public change log is more helpful than assumptions.
Are there already reliable product metrics or a way to sign up?
For Polier by ballmüller solutions, the position as of 01.11.2026 is: in development, not available, tested only against test doubles, no real run against an Azure DevOps organisation, no customer, no certification, no penetration test. Any later measurements would appear on the proof page; the intended sign-up route is listed under sign-up and packages.
Next step
Proceed in a short, fixed sequence:
- fully inventory both bypass permissions,
- reduce the authorised group to a few named responsible people,
- document the emergency process in writing,
- review actual use regularly.
After that, compare your main branches deliberately against Microsoft’s baseline: at least two reviewers, automatically included reviewers for sensitive paths, linked work items, build validation, comment resolution and tightly restricted bypass permissions (Microsoft Learn, “Securely use Git repos and pull requests in Azure Repos”, accessed on 01.11.2026).
If, while doing so, you also want to look at the planned security and data aspects of a coding agent for Azure DevOps: Polier by ballmüller solutions is a concept for a coding agent for Azure DevOps Services, is in development as of 01.11.2026 and is not yet available; it is intended that the customer’s branch policies apply and that the agent itself never merges.