GitHub Copilot code review can now approve pull requests, raising separation-of-duties concerns

GitHub has extended Copilot code review so it can formally approve pull requests rather than only leave comments, according to a changelog item highlighted in an engineering post on dev.to. The capability looks minor in a release note, but it moves AI output from the territory of advice into the controls that decide whether code ships.

From comment to merge control

The dev.to author, writing for engineers responsible for production systems, draws a hard line between the two verbs. A review comment is a suggestion; an approval participates in branch protection, required-review counts, audit logs, deployment gates and package publishing. Once a Copilot approval can count toward a required review, the tool stops being a triage signal and becomes part of the boundary teams have built around the merge button. The author argues that treating Copilot as simply one more reviewer understates the change, describing it as a new merge primitive that needs to be governed like any other participant in that process.

Where a machine sign-off might be acceptable

The post does not argue against AI review. The author compares it to linters, static analysis and good test output: useful for catching obvious problems before humans spend attention on them. Plausible candidates for counting AI approvals include generated documentation, test-fixture updates, formatting-only changes, and mechanical refactors where the compiler, tests and ownership rules already supply strong evidence. The qualifier is that an AI approval should serve as one piece of evidence, never the sole basis for a merge.

The failure mode

The dangerous scenario the author sketches is this: an agent writes a change, a similar agent reviews it, CI passes either because the test suite is weak or because the diff edited the workflow that runs the tests, the approval counts, and the code merges with the appearance of independent review. The author calls this "automation laundering." The proposed first policy is a denylist of sensitive paths where Copilot approvals should not satisfy merge rules, including deployment workflows, authentication and authorization code, payments and billing logic, money movement and reconciliation, secrets handling, CI and release automation, dependency manifests and lockfiles, infrastructure as code, package publishing configuration, incident tooling, and security scanning policy. Copilot could still comment and explain in those areas; it just could not be the sign-off.

Context exclusions become part of approval policy

According to the post, GitHub also made content exclusions generally available for the Copilot app and CLI, which the author considers a good thing for keeping sensitive files out of agent context. But it creates a new obligation: an approval from a reviewer that was not permitted to read the relevant files is weaker evidence. The author draws the human analogy of someone approving an authentication refactor while being barred from opening the policy files or the integration tests. Approval policy, the argument goes, needs to record not only which files changed but also which files the approver was allowed to inspect.

CI is not automatically independent

Gating Copilot approvals on a green CI run is necessary but not sufficient, the post argues. CI counts as independent evidence only when the pull request cannot cheaply compromise the checks meant to constrain it, such as edits to workflow files, reusable workflow references, build scripts, dependency installation, test selection or artifact publishing. The author points to related GitHub changes, including more precise CodeQL detection for GitHub Actions issues, clearer reusable workflow identity context, least-privilege permissions and read-only cache tokens for untrusted triggers, as the right model: automation has trust boundaries, and AI approvals should inherit them rather than sit above them.

A rule the author calls non-negotiable

An agent should not be allowed to approve a pull request primarily authored by the same class of agent, meaning one where the agent planned the change, edited the files, wrote the tests and opened the PR. The author clarifies this is not about ordinary autocomplete or chat assistance, which developers already use all day.

Why it matters

Required reviews are an accountability mechanism: they record who looked at a change, who had enough context to accept the risk, and who was independent of the author. The moment an AI approval can satisfy those rules, it inherits the responsibility they encode. Teams that enable the capability should decide in policy, not by default, where machine sign-offs count: which paths stay human-only, whether agent-authored changes always need a human reviewer, and whether the AI approver could actually read the code it approved. Otherwise, removing the drag of rubber-stamp reviews also removes the independent check those reviews existed to provide.