Copilot Can Now Approve PRs, But AI Approval Requires Separation of Duties

GitHub released a seemingly minor changelog entry: Copilot code review can now approve pull requests. Not comment, not summarize, not politely say "looks fine"—approve. In the merge protocol composed of branch protection, code ownership, audit logs, and deployment gates, this is a completely different verb.

A comment is a suggestion; an approval is part of the protocol. When AI "approval" can count toward the required number of approvals, the question is no longer "should AI review code" but: when AI review is allowed to "count," what duties must it be separated from?

Approval Is Not a Better Review Experience

As an enhanced version of linters, static analysis, and dependency alerts, AI code review has clear value: filtering noise before humans waste attention. Copilot's approval assessment is a useful signal in this context—it may not find blocking issues, may only see low-risk edits, and may help humans triage the queue faster.

But once this approval can count toward required approvals, it shifts from "signal" to "something that can move code from proposed state to mergeable state." This changes the threat model. Teams have spent years teaching developers: the merge button is not just a button; it is a controlled boundary. Rules exist around it because code review is not just about code quality—it is about accountability: Who looked at it? Who has enough context to accept this risk? Is the approver independent of the change author?

If Copilot can now participate in this protocol, it must be governed as a protocol participant. Treating it as "just another reviewer" is lazy architecture. It is a new merge primitive.

Branch Protection is a repository management feature offered by code hosting platforms like GitHub that allows administrators to set a series of merge rules for specific branches (e.g., main, release). Common rules include: requiring at least N approvals, requiring approval from specific code owners (CODEOWNERS), requiring status checks (e.g., CI tests) to pass, prohibiting force pushes, requiring linear history, etc. The core purpose of branch protection is to prevent unreviewed or unverified code from entering critical branches directly, thereby transforming the merge process from an "individual action" into a "controlled protocol." When AI approval can count toward required approvals, it is effectively interacting with the counting logic of branch protection—the platform must clarify whether AI approval is considered a legitimate source for satisfying "at least one approval," which directly determines AI's legal status in the merge protocol.

Code Ownership (CODEOWNERS) is a mechanism provided by GitHub that allows repository maintainers to designate "owners" (usually teams or individuals) for specific files or directories. When a pull request modifies files under these paths, the system automatically requests reviews from the corresponding owners, and can be configured to require owner approval before merging. The design intent of code ownership is to ensure changes are reviewed by those who best understand the risks in that domain, embodying the principle of separation of duties. If AI approval is allowed to replace or supplement code owner approval, this expertise-based review safeguard is weakened. Therefore, when discussing AI approval, it must be clear that it cannot bypass code ownership rules, especially on sensitive paths.

The Useful Version Is Narrow

The scenarios where Copilot approval is genuinely valuable are not hard to imagine: generated documentation, test fixture updates, pure formatting changes, mechanical refactors with strong evidence from compilers and tests, and low-risk generated code where the generation process itself is controlled and reproducible. For these changes, AI approval can reduce human review drag—no one should spend senior engineer attention stamping a thousand-line diff produced by a deterministic tool and verified by CI.

But the keyword is "as part of the evidence." The dangerous version is broader: one agent writes the change, another agent (or the same tool wearing a different hat) reviews it, CI passes because tests are weak or the change modified the test workflow, approval counts, the merge button lights up, and everyone pretends independent review occurred.

This is not separation of duties; this is automation laundering.

Sensitive Paths Should Remain Human-Only

The first policy should be boring and explicit: Copilot approval should not count on sensitive paths. Start with a deny list:

• Deployment workflows
• Authentication and authorization code
• Payment and billing code
• Ledger, reconciliation, and money movement logic
• Secret handling
• CI and release automation
• Dependency manifests and lockfiles
• Infrastructure as code
• Package publishing configuration
• Production incident tooling
• Security policies and code scanning configuration

This is not because Copilot is useless in these areas. It can still comment, explain, flag suspicious patterns, and help human reviewers ask better questions. But its approval should not satisfy merge rules. Using tools to improve judgment and delegating control decisions to tools are two different things. Sensitive paths are where this distinction matters most. If a PR modifies a GitHub Actions workflow, I don't want the same platform that will execute that workflow to be considered an independent approver.

Infrastructure as Code (IaC) refers to defining and managing compute, network, storage, and other infrastructure through code files (e.g., Terraform, CloudFormation, Kubernetes manifests) rather than manual console operations. IaC files are typically tightly integrated with deployment workflows, and once merged may trigger the creation, modification, or destruction of infrastructure. Therefore, IaC change review requires assessing potential impact on production environments, including resource permissions, network exposure, cost, and security configuration. If AI approval counts toward merge rules, it must be ensured that the reviewer (human or AI) can understand the real infrastructure state represented by these files and has enough context to judge whether the change is safe. Since IaC often involves cloud credentials and sensitive configuration, it should be on the deny list, allowing AI to provide comments only, not approvals.

Context Exclusions Are Now More Important

An easily overlooked detail: GitHub also made content exclusions generally available in the Copilot app and CLI. Enterprises need to exclude sensitive files from agent context, which is good. But if agents are allowed to approve code, exclusion policy becomes part of approval policy.

An approval from a reviewer not allowed to read the relevant files is weaker evidence. Imagine a person saying: "I approve this authentication refactor, but I'm not authorized to open the policy file, integration tests, or deployment workflow." You wouldn't treat that as a strong review. The same standard should apply to agents. Approval policy needs to know not just which files changed, but which files the tool was allowed to inspect when forming its approval.

CI Doesn't Automatically Become Independent

The simple answer is: let Copilot approve only when CI passes. This is necessary but not sufficient. CI is independent evidence only when the PR cannot cheaply undermine the checks meant to constrain it. If the change edits workflow files, reusable workflow references, build scripts, dependency installation, test selection, or artifact publishing, then the CI result is itself part of the modified object.

This is also the significance of GitHub's recent series of changes tightening the Actions trust boundary: more precise CodeQL detection of Actions issues, clearer reusable workflow identity context, least privilege, read-only cache tokens for untrusted triggers. The correct mental model is: automation is not a monolith of trust; it has boundaries. AI approval should inherit these boundaries, not float above them.

OIDC (OpenID Connect) is a token-based authentication protocol used in CI/CD scenarios to allow workflows to temporarily obtain cloud resource access without long-term storage of static keys. GitHub Actions supports OIDC integration with cloud providers (e.g., AWS, Azure, GCP), where workflows can request a short-lived JWT token, and the cloud platform grants least-privilege access after verifying the token's issuer and claims. This mechanism reduces key leakage risk but introduces a new trust boundary: if the workflow definition file itself can be modified by a PR, an attacker could tamper with the requested scope or target role of the OIDC token. Therefore, when discussing "CI as independent evidence," the integrity and immutability of OIDC configuration must be considered. If AI approval relies on CI passing, it must be ensured that the CI workflow and its OIDC configuration are not directly affected by the change under review; otherwise, the CI result may be manipulated.

Agent-Written Code Requires Independent Review

One rule should be non-negotiable: an agent should not be allowed to approve a PR primarily written by an agent of the same kind. This is not to say every AI-assisted PR needs a committee—developers use completion and refactoring tools every day. The key is PRs where an agent did substantive work: planning changes, editing files, writing tests, and opening the PR. In such cases, AI approval from the same product family should not count as independent review.

Translated back into human terms, it's clear: we generally don't let authors be their own independent reviewers, and we don't equate "I checked my own work" with review by another qualified person. AI doesn't make this principle obsolete; it just makes violating it easier.

Automation Laundering refers to using automation tools or AI systems to confer false legitimacy or independence on changes, thereby bypassing human review or separation of duties that should exist. In code review, a typical form is: one AI agent writes code, another AI agent of the same kind (or a different instance of the same tool) approves it, making the merge request appear to have undergone "independent review," when in fact the reviewer and author are from the same source and lack a truly independent perspective. Automation laundering is dangerous because it creates an illusion of compliance that may allow flawed or malicious changes to pass through gates meant to block them. Preventing automation laundering requires clear rules: AI approval cannot come from the same tool family as the code author, and for PRs substantively written by agents, approval must come from a human or a completely independent reviewer.

The Policy Ladder

Don't enable AI approval everywhere at once and expect repository administrators to figure it out themselves. Proceed in stages:

Bottom layer: Approval assessment only. Let Copilot express whether it thinks a PR is ready, but don't count it toward required approvals. Observe signal quality, see where it's useful and where it's noisy, and adjust instructions and review intensity.

Next layer: Allow approvals to count only on clearly low-risk paths. Documentation, generated examples, pure formatting, test-only changes, fixture updates, mechanical refactors with strong CI coverage. Require ownership rules and branch protection to pass, and require new commits to automatically dismiss approvals.

Next layer up: Require policy evidence. Approvals should be explainable: Which files changed? Which paths were allowed? Which content exclusions applied? Which checks passed? Was the PR written by a human, an agent, or a mix? Did sensitive path rules trigger?

Then: Let exceptions expire. Temporary policy exceptions should have expiration dates, like temporary budgets. Short-term relaxation during migration is understandable, but permanent exceptions become folklore, and folklore becomes production risk.

Top layer: Keep some human-only repositories. Authentication platforms, payment systems, ledgers, infrastructure modules, release automation, security tooling, and regulated workloads can still benefit from AI comments but should not let tools count as approvers. This is not anti-AI; it is normal engineering judgment.

The Release System Provides the Right Analogy

npm's trusted publishing changes are a good analogy. Modern release systems are moving from long-lived tokens to OIDC-based workflows, separate configuration, staged releases, malware scanning, and explicit human approval before publishing. The pattern is clear: reduce key sprawl, automate boring checks, preserve meaningful gates.

PR approval should evolve in the same direction. If AI review becomes part of the merge path, policy should explicitly state: what tools can approve, what they can only comment on, and where human or independent control must be preserved. The mature answer is not "never let AI approve anything" but "don't confuse convenience with independence."

The Real Risk Is Pretending Nothing Changed

Some will overreact and say machines should never approve PRs. That's too simplistic. We have long let machines block and allow changes in many ways: tests, linters, scanners, policy engines, deployment gates, and generative proofs all participate in software delivery. The problem is not machine participation but unclear authority.

When a linter fails, we know what that means; when CodeQL flags a vulnerability, we know what kind of evidence it provides; when branch protection requires two approvals, we know the human accountability model we intend. AI approval muddies all this unless we define it carefully. Does Copilot approval mean the code is correct? No. Does it mean there are no security issues? No. Does it mean the tool found no blocking concerns within the context and policy it was allowed to use? That's closer.

If that's what it means, then policy needs to state where this evidence is strong enough to count.

My inclination is simple: let AI review aggressively but approve conservatively. Use it to reduce noise, catch boring errors, summarize risk, and sharpen human review. But when approval becomes part of merge control, stop treating it as a productivity feature—treat it as a security and governance feature. Separate duties, name paths, preserve independence, and keep the audit trail boring. Agent approval itself is not bad; pretending it is "just another reviewer" is.

One-line Summary

Copilot can approve PRs, raising governance questions: AI approval should be conservative, requiring separation of duties and human-only sensitive paths.

Paragraph Summary

GitHub Copilot code review has added an "approve" capability, enabling AI to count toward a pull request's required approvals, which changes the threat model of the merge protocol. The article argues that AI approval should not be seen as a better review experience but as part of the evidence, strictly limited to low-risk paths. Sensitive paths (such as authentication, payments, CI workflows, and secret management) must remain human-only approvals. Content exclusion policies directly affect approval quality, and CI independence depends on it not being cheaply undermined by PRs. Agents should not approve PRs written by agents of the same kind; otherwise, it constitutes automation laundering. A policy ladder is recommended: start with signal assessment only, gradually open low-risk paths, require explainable policy evidence, set expiration dates for exceptions, and keep some human-only repositories. The core principle is to let AI review aggressively but approve conservatively, treating it as a security and governance feature rather than a productivity feature.