Copilot Can Approve Pull Requests—Do Not Let One Agent Close the Review Loop

On September 1, 2026, GitHub placed Copilot code review approvals into public preview; its release notice for the approval option says an administrator can let Copilot submit a review that satisfies a repository’s required-approvals rule.

The capability is off by default, so existing repositories do not silently begin accepting Copilot approvals. Independent coverage published September 2 corroborates the public-preview status, the administrator opt-in and the effect on required approvals.

An assessment is not an approval

Every Copilot code review now includes an approval assessment in its overview comment. This indicates whether Copilot considers the pull request ready, but the assessment itself does not count toward merge requirements.

A formal approval is a separate review action that administrators must authorize. Once enabled, it can reduce the number of outstanding approvals before a repository’s merge rule is satisfied. If another commit is pushed after Copilot approves, that approval is dismissed and a fresh Copilot review can be requested.

The change therefore affects one specific gate: the required-approval count. It does not, by itself, satisfy status checks, deployment controls or any other conditions separately imposed on the branch. Teams need to distinguish “Copilot approved this revision” from “this pull request is eligible to merge.”

Approval authority follows the administrative hierarchy

GitHub divides control among enterprise, organization and repository administrators. An enterprise can keep approvals disabled throughout its scope or allow organizations to decide. An organization can enable the option broadly, restrict it to selected repositories, delegate the choice to repository administrators or leave it disabled.

Repository administrators can turn Copilot approvals on or off and specify which file paths Copilot may approve. These settings determine where an automated approval is permitted; they do not classify the operational risk of each repository or path.

Path controls provide the narrowest native boundary. A team could classify documentation and selected test fixtures as lower risk while reserving authentication code, production deployment definitions, database migrations and payment logic for human approval. Those are policy examples, not categories assigned automatically by GitHub.

AI-to-AI review is already occurring at scale

The governance concern is not hypothetical. A 2026 study of AI-to-AI GitHub reviews identified 248,641 unique AI-attributed pull requests with at least one AI-attributed review: 208,145 received same-product review, 45,269 received cross-product review and 4,773 appeared in both groups. The researchers linked attributed pull requests and review events in public data covering 2024 through 2026.

The attribution method relies on detectable product signatures, so the authors treat the counts as lower bounds. The study also uses “closed-loop” in a deliberately narrow sense: an AI-attributed author and AI-attributed reviewer appeared on opposite sides of the same pull request. It does not establish that humans were absent, that the review became a formal approval or that the pull request merged.

That distinction matters, but it does not remove the independence problem. An authoring agent and reviewing agent may belong to the same product family or share instructions, repository context and failure modes. Automated review can supply useful evidence without supplying the organizational accountability expected from an independent approver.

A safe rollout needs risk tiers beyond the switch

The available controls support a staged policy, but administrators must provide the risk model. A defensible rollout can assign a separate purpose to each layer:

• Enterprise: retain the default-off position and delegate authority only to organizations with a named policy owner, auditable configuration and a rollback process.
• Organization: permit approvals only in selected repositories instead of activating them across every project.
• Repository: preserve existing merge checks and require an independently accountable human when AI authored or materially revised a change.
• Paths: allow Copilot approvals to count only for explicitly classified low-risk files, while sensitive paths retain mandatory human approval.

These are governance recommendations, not built-in guarantees. GitHub’s preview controls where Copilot may approve, but the published feature description does not specify a rule that identifies every AI-authored change or prevents the same product family from contributing on both sides of a review.

An authorship-triggered policy therefore needs a dependable way to identify AI contributions, followed by a required check or review rule that contributors cannot bypass by omitting an attribution marker. If detection is unreliable, applying the independent-human requirement to every change in a sensitive path is safer than trying to classify its author.

High-risk code should retain a human gate

For sensitive paths, the clearest invariant is that a Copilot approval cannot be sufficient by itself. Lower-risk paths may allow it to count, but repositories can still require another approval from a named person accountable for the decision.

CODEOWNERS review requirements, restricted approval-dismissal permissions and tightly limited ruleset bypasses can help preserve that separation. Their effectiveness depends on the repository’s complete configuration, so audit records should capture who enabled Copilot approvals, which repositories and paths are eligible, and whether later changes widened the scope.

The capability remains an opt-in public preview with controls at several administrative levels, and an enabled approval can satisfy the ordinary required-approvals rule. What remains unresolved is whether GitHub will add native enforcement for AI-authored changes or reviewer independence. Until then, high-risk repositories need a separate human decision that an automated author-reviewer loop cannot close by itself.

Also read:

• Your Code Is Not the Promotion Case: 4 Moves That Show Wider Impact
• Medication Apps Can Improve Adherence—Not Replace a Drug Review
• Social Reach Is Not Revenue: Build a Content System That Measures Both