On September 1, 2026, GitHub announced in public preview that Copilot Code Review could not only indicate that it considers a pull request ready, but also submit an approval that counts toward merge rules when an administrator enables this capability. The feature is disabled by default and can be configured at enterprise, organization, and repository levels, with an optional restriction by file paths. This development can speed up routine changes; above all, it changes the trust boundary of the delivery pipeline.
Key takeaway: an agent's opinion can complement a review, but it must never become the sole control for a sensitive change, nor approve a change produced by the same pipeline without independent validation. Protected branches, tests, CODEOWNERS, separation of duties, and traceability remain the main safeguards.
1. Distinguishing assessment from approval
GitHub introduces two different behaviors. Every Copilot review can include an assessment stating whether the pull request appears ready for approval. That indication appears in the summary comment but does not meet merge requirements.
When the option is enabled, Copilot can submit an actual approval. It can count toward the number of approvals required by the protection rule. If new commits are pushed after approval, GitHub states that the approval is dismissed, just as a human reviewer's approval would be, and a new review must be requested.
This distinction must remain visible in both the interface and procedures. A developer must not confuse “the model found no blocking issue” with “the change is authorized to enter production.” The first statement describes a signal. The second entails accountability and contributes to a control decision.
Initially, the non-counting assessment can be enabled broadly to measure how relevant the signal is. Actual approval should remain limited to repositories and paths whose risk has been assessed.
2. Why approval is authority, not a comment
A code review produces comments. An approval changes the state of a pull request and can unblock automatic merging. It is therefore a tool call with consequences, comparable to adding a deployment label or validating an infrastructure change.
The central question is not “Can Copilot detect defects?” It is: under what conditions can its judgment replace part of the mandatory control? A human reviewer may know the business objective, the component's history, a customer constraint, or an operational dependency that does not appear in the diff.
The model can also be influenced by repository content: comments, documentation, file names, or embedded instructions. Even when the platform applies protections, the analyzed data remains untrusted input. An important rule must not depend solely on a probabilistic system that reads the change it is expected to authorize.
Correlated failures must also be considered. If the same provider, model, or instruction generates the code and then approves it, the two steps can share the same blind spots. Adding more agents does not automatically create independence.
3. Preserving separation of duties
The minimum principle is this: a change must not be created and approved by the same logical identity without another independent control. If Copilot or an agent opens the pull request, its approval must not be enough to merge it.
This rule can be applied through provenance. Add an attribute to pull requests showing whether the change is human-made, assisted, or generated by an agent. Merge rules then require human validation for agent contributions, even when a Copilot review is present.
For simple human changes, Copilot can provide a supplementary approval. The organization may decide that it counts as one of two approvals, but not as the final approval for a critical component. A CODEOWNER remains accountable for the scope.
Separate configurations as well. The account managing approval rules must not be modifiable by the workflow being assessed. Changes to enterprise settings, branch protection, and policy files must go through a restricted group and human review.
Finally, Copilot's identity must be explicit in the history. An automated approval must not appear to come from a team member. The audit trail must make it possible to identify the model, feature version, date, reviewed commits, and controls available when the decision was made.
4. Defining paths that AI cannot approve on its own
GitHub lets administrators choose the paths that Copilot is allowed to approve. This capability should be used as an allowlist: approval is valid only in areas explicitly considered low risk.
An initial scope can include documentation changes, examples, translations, tests that do not change production, development dependencies, or repetitive fixes in a well-covered component. Even in those areas, tests and volume limits remain necessary.
At a minimum, exclude:
- secret, identity, and permission files;
- CI/CD workflows, deployment scripts, and infrastructure;
- database migrations and schemas;
- authentication, payment, encryption, or access-control code;
- security policies, CODEOWNERS, and protections;
- production dependencies and lock files when their impact has not been analyzed;
- regulated code or code subject to contractual validation;
- large, generated, or difficult-to-review changes.
Sensitivity does not depend only on the path. Documentation can contain a dangerous operational command; a test can disable an assertion. Add rules for diff size, file type, changed permissions, and the presence of risk markers.
Paths must be reviewed whenever the architecture evolves. A formerly static directory can become a source of active configuration.
5. Strengthening branch protections and CI
Copilot approval must not bypass existing controls. Require an up-to-date branch, mandatory CI statuses, no unresolved conversations, signed commits where policy requires them, and dismissal of approvals after changes.
Tests must cover more than syntax. Add static analysis, dependency checks, secret scanning, migration checks, API contracts, permissions, and security tests appropriate to the component. An AI review can comment on an intent; CI provides reproducible evidence.
Use a merge queue to prevent an approval from validating a state different from the one actually integrated. The queue reruns checks on the final combination of changes and limits conflicts between separately approved pull requests.
For high-impact repositories, require a staging environment or separate deployment validation. Code can be correct locally and still have an unexpected effect on data, configuration, or observability.
Do not give the agent the ability to modify mandatory tests in the same workflow it approves. When a change affects CI, policy, or evaluation datasets, a dedicated human review is required.
6. Assessing review quality before enabling it
Start by observing non-counting assessments. Over several weeks, compare Copilot's judgment with human reviewers' outcomes, post-merge incidents, and production feedback.
Build a set of historical pull requests containing known defects: a logic bug, missing access control, a risky migration, concurrency, a compatibility break, a data leak, a weakened test, and a legitimate documentation change. Measure what Copilot detects, what it misses, and what it blocks incorrectly.
Useful metrics include recall for critical defects, the false sense-of-security rate, the number of actionable comments, review time, and the human-disagreement rate. An overall agreement rate can be high while masking the rare but most serious errors.
Also test robustness: a conflicting instruction in the repository, a very large diff, generated code, mass renaming, a submodule, and a binary file. Verify that the system abstains when context is incomplete or the pull request is outside its scope.
Repeat the assessment after every significant model or feature change. A public preview evolves; a result obtained in September 2026 does not guarantee the same behavior several months later.
7. Rolling out in stages and planning rollback
The first stage is informational: Copilot comments and publishes its assessment without counting in the rules. The second allows approval on a low-risk repository but still requires human approval. The third lets the approval satisfy a rule only for a very limited list of paths and changes.
Do not enable it globally at enterprise level before observing behavior by repository type. Use the settings hierarchy to let organizations or repositories explicitly join the pilot.
Define stop thresholds: an undetected critical defect, too high a false-positive rate, divergence from reviewers, an undocumented behavior change, or a post-merge incident. Disabling must be immediate and must not require changing every repository individually.
Keep a history of decisions. When a team expands allowed paths, it supplies assessment results and the risk owner. Authorization expires automatically if it is not reviewed.
After rollout, sample pull requests approved by Copilot and perform a retrospective review. The absence of a visible incident does not prove the absence of a defect; continuous control prevents the feature from becoming a forgotten automatism.
8. A reference policy for organizations
A simple policy can be stated as follows:
- Copilot assessment is an advisory signal by default;
- actual approval is disabled at enterprise level, except under explicit delegation;
- only repositories enrolled in the pilot may enable it;
- authorized paths are defined positively;
- agent contributions always require human approval;
- sensitive files and policy changes are excluded;
- CI statuses and CODEOWNERS remain mandatory;
- every new commit dismisses the decision and triggers a new review;
- behavior is assessed and audited periodically;
- a central mechanism allows immediate disabling.
This policy must be accompanied by examples, because teams must understand what constitutes a simple or sensitive change. It must also state that technical approval does not replace product, legal, or security validation required by some projects.
Feedback from Asana and the use of Codex for a technical-debt migration underscores the importance of strong test coverage and human review of every change, even when agents greatly accelerate the work.
Conclusion
Allowing Copilot to approve a pull request can reduce the latency of routine changes, but it gives a probabilistic system a role in the merge decision. This role must be treated as a delegation of authority rather than a simple enriched comment.
The robust framework rests on authorized paths, separation between author and approver, branch protections, independent CI, CODEOWNERS, local assessments, and gradual rollout. Partitech supports teams in designing these policies, GitHub automation, and integrating development agents without weakening control over delivery.
References verified on September 3, 2026
- GitHub — “Copilot code review can now approve pull requests,” September 1, 2026: https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests/
- GitHub Documentation — branch protection and pull-request rules: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository
- GitHub Documentation — CODEOWNERS: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners