AI coding agents in regulated companies can only be assessed with confidence if the data path, identities, technical guardrails and their current status are documented separately. For your assessment, what matters most is how a tool is embedded in pull requests and branch policies, where human approvals remain in place, and which statements remain unproven without real evidence.
What matters is not the feature list but how far it intervenes in your existing control framework in Azure DevOps. You should be able to see which identity performs which action, which blocks are technically enforced, and how far development has actually progressed; a public change log helps with that.
A branch policy is a rule in Azure Repos that enforces certain checks or approvals before a pull request can be completed.
For an initial assessment, three perspectives are often enough:
- Security and data path
- Integration into review and approval processes
- Operating model and planned procurement, for example via allowances and sign-in route
For related questions, it also helps to understand how to assess AI review comments correctly and to have an overview of options and costs for AI code review in Azure Repos.
Why regulated companies hesitate
In regulated companies, the assessment of an AI coding agent rarely starts with the feature set. For information security and data protection, it is usually more important first to establish whether the tool can be clearly delimited: in business, technical and organisational terms.
As soon as a system works with work items, source code and pull requests, questions arise that go beyond product features alone. The main focus is usually on these points:
- what content the system is meant to see and process,
- the environment in which that processing takes place,
- which logs and evidence will later be available,
- how responsibilities are divided between provider and customer,
- and whether existing review and approval routes remain fully effective.
There is also the question of actual maturity. For risk and data protection assessments, there is a considerable difference between a technical plan, tests against test doubles and deployment in a real Azure DevOps organisation. Without real runs, independent audits or certifications, important statements remain open.
The operating model is often the real sticking point as well. If customer code is to be processed by the provider, the issue is not just security, but regularly also data processing under instruction, data flows, retention and possible access paths. For data protection, DORA, NIS2 and co-determination, these are different issues; have them reviewed separately by your legal department, your data protection officer and, where applicable, your works council.
Additional caution arises when AI features in Azure-DevOps-related scenarios are themselves still preliminary. According to Microsoft Learn “Sprint 279 Update” and the pages on “Copilot code reviews” (read on 01/11/2026), Copilot Code Review is in Public Preview; preview features have no SLA and may change. For robust approval and control processes, that status is part of the assessment, not just a side note.
Controls that can make an agent acceptable
An AI agent only becomes acceptable in regulated environments when its technical role is tightly limited. For your assessment, it helps to use a control model that cleanly separates proposal, review and decision.
What matters first is the link to Azure Repos policies. According to Microsoft Learn “Branch policies overview”, “Branch policies” and “Secure repositories with branch policies and pull requests” (read on 01/11/2026), Azure Repos allows you to define pull-request rules including minimum number of reviewers, linked work items, comment resolution, build validation, status checks and automatically included reviewers; by default, these rules are turned off.
For an agent, the key point is that it works within this framework rather than alongside it. What matters most is:
- no completion outside the review process,
- no bypassing of branch policies,
- no special rights to push or complete,
- visible attribution of all actions to an identity,
- traceable linkage between work item, changes and pull request.
A status check is an automated check in a pull request that can be required as a condition for completion.
The assignment of permissions is equally important. In “Secure repositories with branch policies and pull requests” (read on 01/11/2026), Microsoft recommends restricting the permissions “Bypass policies when completing pull requests” and “Bypass policies when pushing” to a small administrator group. For risk assessment, this is a central point: an agent that does not need such permissions changes your control framework less fundamentally.
Then comes the audit trail. In a robust configuration, it should remain clear afterwards
- which input led to a change,
- which automated checks were run,
- which status was set,
- and where the human decision sits in the flow.
Finally, you should consider data storage and model processing separately. According to Microsoft Learn “Data privacy for Azure OpenAI in Azure AI Foundry Models” (read on 01/11/2026), prompts and completions are not used to train foundation models without permission; however, with Global and DataZone deployments, processing may take place outside a single geography, while data at rest remains in the defined geography. For data protection and outsourcing questions, it therefore matters not only where data is stored, but also where model calls are processed. You should review these points separately with your legal department or your data protection officer.
What remains a human decision
Even with extensive technical checks, responsibility in regulated companies remains with people. A tool can provide pointers, trigger checks and structure results. But it does not remove either your professional responsibility or your organisational responsibility.
That is why several decisions should typically remain explicitly human:
- whether a change is appropriate in business terms,
- how risks in security-relevant paths should be assessed,
- whether an exception case exists,
- whether approval should be granted despite residual findings,
- and how aims such as speed, traceability and separation of duties should be balanced against each other.
Pull requests in particular can easily lead to a false assumption: that if an AI system provides a review, it has already replaced a required approval. That is not the case in Azure Repos. According to Microsoft Learn “Review pull requests” and “Copilot code reviews” (read on 01/11/2026), Copilot Code Review always leaves a Comment Review. That does not satisfy a Required Reviewer policy and does not block the merge.
The practical conclusion is clear: AI hints in pull requests can be useful, but as a rule they do not replace human approval where your branch policies require human reviewers.
There are also operational limits. According to Microsoft Learn “Copilot code reviews” (read on 01/11/2026), only active pull requests without merge conflicts are reviewed, in repositories up to 10 GB and with up to 100 changed files and 100 changes; there are also limits for parallel reviews. You should take such limits into account when assessing how reliable the process is.
If you want to distinguish more clearly between options and pricing models for AI code review in Azure Repos, there is a separate in-depth article on the blog.
Common questions you might ask about this
Is a pull request agent without merge rights enough for approval?
No. For the assessment, what matters is not only whether a tool merges itself, but what place it is given in the process. A pull request can be technically integrated cleanly into the existing flow and still trigger additional review requirements.
Pay particular attention to three points:
- Which identity creates branches, pushes commits or sets status?
- Whether that identity is given special rights that your team would otherwise grant only very selectively.
- Whether completion still takes place exclusively under your branch policies.
A status check is an automated test signal in the pull request that you can require as a mandatory condition.
Which branch-policy questions matter most for the assessment?
It makes sense not to treat every available policy as equally important, but to review first those with a direct impact on traceability and approval. According to Microsoft Learn “Branch policies overview”, “Branch policies” and “Secure repositories with branch policies and pull requests” (read on 01/11/2026), all branch policies are initially switched off.
For your assessment, these settings are usually the most relevant to look at first:
- Minimum number of reviewers
- Build validation
- Status checks
- Linked work items
- Automatically included reviewers
- Comment resolution
You should also read the detailed options of the reviewer policy, for example whether requesters may approve their own changes or whether approvals are reset when new pushes are made.
Is the merge strategy itself a security feature?
Not directly. According to Microsoft Learn “Secure repositories with branch policies and pull requests” and the guidance on merge types (read on 01/11/2026), “Limit merge types” is primarily a rule about history. In other words, it controls how the Git history is written.
That can still matter for internal controls. Squash produces a more compact history, but combines the commits from the source branch. If your review model needs the exact sequence of commits, you should agree this setting deliberately with development, audit and, where applicable, compliance stakeholders.
What changes if Azure DevOps does not remain the final state later on?
For some companies, this also includes the question of path dependence. According to Microsoft Learn “Sprint 279 Update” (read on 01/11/2026), enterprise live migrations can transfer repository history, branches, tags, pull-request metadata and branch policies, while Boards and Pipelines can continue to be used.
For your assessment, that means: review not only today’s process, but also whether identities, audit trails and policies will still remain understandable after a later platform change.
How should a new offering in this area be classified?
With a new service, you should clearly distinguish between planning, test status and robust operations. If a provider is still in development, has not yet had any real runs against an Azure DevOps organisation and has neither certification nor a penetration test, then security and data protection questions remain open and must be documented as open.
That also applies to Polier: the service is in development and, as of 01/11/2026, is not yet available. For now, the assessment therefore mainly concerns architecture, role model, planned data path and the question of which statements are not yet supported by real-world use.
Next step
It makes sense to assess an AI coding agent not first as a product category, but as a planned change within your existing Azure DevOps control framework. That keeps the review close to the questions that are actually relevant for information security, data protection and governance.
A pragmatic order is often:
- first document the data path and identities,
- then review branch policies and status checks,
- then clarify logging and retention,
- and only afterwards discuss a pilot.
You should review legal and data protection issues with your legal department or your data protection officer. If functions may be affected that are relevant for co-determination, it also makes sense to involve the works council at an early stage.
If you would like to follow the development status of Polier: Polier is a coding agent for Azure DevOps that is in development and, as of 01/11/2026, is not yet available.