In Azure Repos, who can push, complete pull requests and bypass rules is determined not by a single role, but by the combination of security groups, repository and branch permissions, and branch policies. Direct pushes to protected branches, and bypass rights in particular, should therefore be limited to a small number of administrative accounts; the normal route for integrating changes is via pull requests within the rules you have set.
A branch policy is a server-side rule enforced for pull requests. In Azure Repos, Microsoft lists the following available policies: minimum number of reviewers, linked work items, comment resolution, merge types, build validation, status checks and automatically included reviewers; all are switched off by default (Microsoft Learn, “Branch policies overview” and “Branch policies”, accessed on 01/11/2026).
In practice, this means you should always review permissions and policies together. Only this combination gives you a reliable view of who can actually write to a branch, complete a pull request or technically bypass protection rules.
Security groups and the permissions that matter in repositories and branches
For day-to-day practice, looking only at project level is not enough. What matters is the combination of rights at project, repository and branch level. Only there can you see who can actually write, complete a pull request or use exceptions on a protected branch.
Where possible, assign such rights through security groups rather than directly to individuals. In operation, this is easier to track, simpler to maintain and less error-prone when people change roles or leave. Especially for protected branches, a small, clearly named group structure is more helpful than lots of individual exceptions.
For this article, one distinction is central:
- pushing to a branch
- completing a pull request
- bypassing branch policies
These are separate capabilities and should be checked separately. Someone who can write code to a branch does not automatically need to be able to complete a pull request against that same branch. And someone who can complete a pull request should not automatically have the right to bypass policies.
What matters here is branch level. Even if broader rights exist at repository level, you can set tighter rules for individual protected branches. That is exactly where many organisations separate the ordinary path from exceptions: feature branches remain more flexible, while main and release branches are granted more restricted rights. Typical candidates are main, master or release/*, but that is common practice rather than a fixed rule.
In its security baseline for main, Microsoft recommends restricting the permissions “Bypass policies when completing pull requests” and “Bypass policies when pushing” to a small admin group, requiring at least two reviewers, automatically including reviewers for sensitive paths, checking linked work items, adding build validation and requiring comment resolution (Microsoft Learn, “Secure Azure Repos by using branch policies”, accessed on 01/11/2026).
In Azure Repos, the available branch policies are minimum number of reviewers, linked work items, resolved comments, restricting merge types, build validation, status checks and automatically included reviewers; all are switched off by default (Microsoft Learn, “Branch policies overview” and “Branch policies”, accessed on 01/11/2026).
Bypass permissions – and why they should remain rare
Bypass rights are not about convenience, but about exceptions to the intended review path. Two permissions are relevant: “Bypass policies when completing pull requests” and “Bypass policies when pushing”. The first allows a pull request to be completed despite policies not being met; the second allows direct writes to the protected branch. For main, Microsoft recommends restricting both permissions to a small admin group (Microsoft Learn, “Secure Azure Repos by using branch policies”, accessed on 01/11/2026).
In practice, the fine settings of the reviewer policy are crucial. According to Microsoft Learn (“Branch policies”, accessed on 01/11/2026), you should set these points consciously in particular:
- whether requesters may approve their own changes
- whether the person who pushed most recently may approve themselves
- whether, after new pushes, at least one approval on the latest iteration is required
- whether approvals or all reviewer votes are reset after new pushes
An iteration is the state of a pull request after another push. These options in particular often determine whether a review still stands up after changes or simply continues in a purely formal sense.
For work that is not yet settled, a pull request marked as open is usually the cleaner route than permanently granting broadly distributed exception rights.
Separate from that, you should place “Limit merge types” in context. According to Microsoft, this policy primarily controls history and is not a direct security control instrument (Microsoft Learn, “Secure Azure Repos by using branch policies”, accessed on 01/11/2026). Whether you allow Squash, Rebase or Merge Commit is above all a question of how traceable you want your commit history to be; our overview of merge strategies in Azure Repos fits well here.
Branch permissions versus policies: what each is for
Branch permissions and policies take effect in different places. Permissions control access to Git actions. Policies control the pull request process on the target branch. In practice, this means policies check the intended route, but not every other way of writing alongside it.
For additional technical checks, status checks are the right building block. A status check is a machine-generated response to a pull request that you can make mandatory. This lets you plug internal or connected validation steps into the merge flow without reinterpreting required reviewer rules.
It is important to distinguish this from the current AI review in Azure Repos. Microsoft states that Copilot code review always leaves a Comment review. It therefore does not satisfy a Required reviewer policy and does not block completion (Microsoft Learn, “Review pull requests” and “Copilot code reviews”, accessed on 01/11/2026).
According to Microsoft, there is also currently a narrow technical scope:
- only active pull requests without merge conflicts; for handling these, see resolving merge conflicts in Azure Repos
- repository size up to 10 GB
- up to 100 changed files and 100 changes; for context, see How large should a pull request be?
- limits on concurrent reviews per pull request, organisation and user
In addition, the feature is in Public Preview. According to Microsoft Learn (“Sprint 279 Update” and “Copilot code reviews”, accessed on 01/11/2026), it may change, and preview features have no SLA. For protected branches, that is not a detail, but part of the operational assessment.
If you want to place the use of such checks in a broader strategic context, it often helps to start with decision criteria between Azure Repos and GitHub.
Clearly separating service identities and automation
Technical identities should be treated separately from human accounts. For branch protection, it is important not only what an account can do, but also what it is intended for. A build service, a bot and an administrative account should therefore not carry the same rights.
A compact role model makes sense:
- accounts that write changes to working branches
- accounts that create or update pull requests
- accounts that only report validation results as a status to a pull request
- a small number of accounts for genuine exceptions
The last point in particular should remain tightly controlled. Accounts used for automation often do not need direct write access to protected target branches and do not need the right to bypass policies. For many workflows, it is enough to generate commits outside the protected branch and let the rest proceed through the pull request path.
Where connected validation is involved, the status identity is especially relevant. A status check is a machine-generated response to the pull request that you can require by policy. This lets you integrate automation in a controlled way without reinterpreting required reviewer rules. The technical identity then reports a result, but it does not replace a human approval.
If you are assessing a service with code access, questions of processing, roles and boundaries belong on the table from the outset. For a planned offering such as Polier, the public change status states: as of 01/11/2026, it is in development and not available; a separate instance per customer is planned in Germany West Central, with its own database, storage, Key Vault, Service Bus and Container Apps environment; the agent is never intended to merge by itself. Information on subscriptions, quotas and sign-up can be found on the page on preliminary packages. There are no metrics yet; the page intended for that is currently empty. For data protection, DORA, NIS2 and co-determination, you should have the specific setup reviewed with your legal department, data protection officer or solicitor.
Common questions when securing Azure Repos
Which reviewer settings determine whether a pull request is still properly reviewed after new pushes?
Often, it is not just the minimum number alone, but the details of the reviewer policy. The following options from Microsoft Learn “Branch policies” are particularly relevant (accessed on 01/11/2026):
- whether requesters may approve their own changes
- whether the person who pushed most recently may approve themselves
- whether, after new pushes, an approval on the latest iteration is required
- whether approvals or all reviewer votes are reset
An iteration is the state of a pull request after another push. Especially on protected branches, these switches shape whether a review is substantively re-secured after changes or simply remains in place formally.
Is “Limit merge types” a security measure?
Not directly. In “Secure Azure Repos by using branch policies”, Microsoft classifies “Limit merge types” as controlling history, not as a direct security mechanism (accessed on 01/11/2026).
In practice, that means the setting is important for traceability, your audit model and commit history, but it does not replace reviewers, build validation or status checks.
Can an AI review be triggered automatically by policy?
Yes. In Azure DevOps Services, according to Microsoft, the current code review feature can be triggered automatically via branch policy; it can also be enabled at organisation, project or repository level and supplemented with custom instructions (Microsoft Learn, “Sprint 279 Update” and “Copilot code reviews”, accessed on 01/11/2026).
For operations, you should also consider the limits:
- Public Preview with no SLA
- only active pull requests without merge conflicts
- repositories up to 10 GB
- up to 100 changed files and 100 changes
- limited concurrent reviews per pull request, organisation and user
Which data and legal questions should I clarify before enabling AI review?
In the FAQ on code reviews, Microsoft notes that this feature’s data residency is not tied to the data residency boundaries of your Azure DevOps organisation; processing may therefore take place in another geography even if your organisation is hosted in the EU, for example in the United States (Microsoft Learn, “Copilot code reviews FAQ”, accessed on 01/11/2026).
Check such points in advance with your data protection officer or solicitor. The same applies to DORA, NIS2 and co-determination.
Next step
Set a short review cadence for protected branches rather than assigning rights only once. What matters is not just the configuration itself, but also whether it still fits your approval model after reorganisations, tool integrations or team changes.
A small checklist is practically useful:
- Which branches are considered particularly in need of protection?
- Which exceptions are consciously intended?
- Which settings should be the same everywhere, and which may differ by repository?
- Who reviews changes to this model regularly?
If you are assessing the use of a coding agent in this environment, pay close attention to its maturity level: as of 01/11/2026, Polier by ballmüller solutions is in development and not available. It is planned for Azure DevOps Services to create a pull request in Azure Repos from an Azure Boards work item; the customer’s branch policies are intended to apply, and the agent itself never merges.