GitHub Copilot Can Now Approve PRs, Raising AI Governance Stakes

For most of its short life, AI code review was advisory furniture. It sat in the pull request, made comments, and could be ignored without consequence. That arrangement ended on September 1, 2026, when GitHub moved Copilot's approval assessment into public preview and gave administrators the option to let a Copilot approval count toward a repository's required-approvals rule — the mechanism that guards the merge button itself1547. Ten days later, GitHub layered on automatic resolution of Copilot's own comments, shell-tool execution during reviews, and an ensemble of agents at the Lite effort level1916. The timing is not incidental. Copilot code review crossed 60 million reviews after launching in April 2025, more than one in five code reviews on the platform, with over 12,000 organizations running it automatically on every pull request1117. A suggestion layer at that scale is a curiosity. A control plane at that scale is a governance problem, and it is the reason the question of how to evaluate AI code governance tools has moved from a compliance backwater to the front of the queue.

From advice to authority

The September changes matter because they change what a Copilot review is. Until this month, Copilot left a Comment review — never Approve or Request changes — and GitHub's documentation was explicit that it did not count toward required approvals15. Now an administrator can authorize Copilot to submit an approving review that satisfies branch protection, which means a bot can close a review loop that previously required a licensed human1547. The surrounding feature work reinforces the shift: Copilot now resolves its own comments once a commit addresses them, writes commit messages when you apply its suggestions, uses a broader set of shell tools to validate the code it reviews, and combines findings from multiple agents at the Lite effort level1916. In the same month, GitHub expanded coverage to pull requests authored by bots — including Copilot's own cloud agent — and to very large pull requests, with usage billed directly to the organization when there is no Copilot-licensed author to attribute12. Resolution reasons, added in late August, let developers record why they dismissed a Copilot comment, which is the first genuinely governance-shaped feature in the product: it treats dismissals as data rather than noise12.

The footprint is also widening beyond github.com. Copilot code review is now in public preview for Azure Repos, available to all Azure DevOps customers, with branch-policy-driven automatic reviews, custom instructions, Managed DevOps Pools support, and improved cost visibility14. Copilot code review went generally available on an agentic architecture on March 5, 2026 for Copilot Pro, Pro+, Business, and Enterprise plans, replacing the earlier single-pass model, and now runs on GitHub Actions17. Custom instructions lost their 4,000-character cap in June 2026, and AGENTS.md is honored17.

The measurement problem

If you are evaluating AI code review tools, the obvious first question is which one finds the most real issues. The honest answer is that nobody knows, and the published numbers disagree with each other enough that they cannot be the deciding factor. A ranking of twelve tools records Copilot at a 54% findings rate in one third-party test and 24.6% in another; CodeRabbit at 44% versus 28.7%; Greptile at 82% in its own test versus 36.1% externally13. The one figure that stands apart is Anthropic's claim for Claude Code Review — findings on 84% of pull requests over 1,000 lines, with under 1% marked incorrect — but it is the vendor's own measurement13. GitHub's self-reported numbers cut the other way in an instructive fashion: 71% of Copilot reviews produce actionable feedback averaging 5.1 comments, and the remaining 29% come back clean rather than generating noise11. That is a claim about review behavior, not accuracy, and it is the kind of metric vendors prefer precisely because catch-rate benchmarks are so unstable.

The most credible public evidence is the .NET team's own account: running the Copilot coding agent on the dotnet/runtime repository for ten months, it produced 878 pull requests and merged 535, a 67.9% success rate11. That is a serious, sustained, real-repository result — and it still doesn't tell you what the tool misses. Divergent benchmark numbers across vendors and independent testers are the single clearest argument for treating evaluation as a layered exercise rather than a bake-off: the top-line accuracy number is the layer you can least trust.

Governance has layers, and the vendors know it

The governance-tooling coverage converges on one structural claim from several different directions: no single product covers the problem, and the layers do not compose themselves. CodeRabbit's framework for engineering leaders describes four governance layers closing the gap between agents that open PRs and humans who review them, covering identity, access control, permission boundaries, audit trails, and human checkpoints — explicitly noting that traditional SAST was never designed to enforce any of that5. Augment's guide to governing agent-written code makes the sharpest distinction in the field: artifact gates evaluate only the finished code that reaches the decision point, at which an agent-authored change looks identical to a hand-written one, so the record that actually separates them — context gathering, tool calls, retries, test edits — lives in the system that ran the agent, and evaluators should ask which candidates enforce at that layer versus merely report3.

The same layered logic appears at a different layer in the gateway camp, which argues that governance belongs where every AI request flows: unified control across Claude Code, Cursor, and Copilot, token-level budgets and rate limits, MCP tool governance for the servers agents wire in, and shadow-AI coverage so agent traffic actually routes through the policy layer, including traffic from the laptop97. Checkmarx frames its platform as layered defense across the full development lifecycle, combining SAST, DAST, SCA, secrets detection, and malicious package protection with AI-specific controls8. Endor Labs treats open source AI models as dependencies — discovered, evaluated, and policy-enforced inside the SCA platform, because traditional SCA never detects them and they never reach the SBOM6. Quality Clouds argues for a documented governance baseline before scaling AI tooling, with deterministic quality gates that separate what the LLM produced from what governance approved, and cross-platform audit trails spanning ServiceNow, Salesforce, Dynamics, and AI-native platforms110. And for European teams, the compliance frame is now concrete: EU AI Act Articles 11, 12, 13, 14, and 50 impose technical documentation, logging, transparency, human oversight, and disclosure duties, with an honest accounting showing what each coding tool produces as a compliance artifact and what remains for the organization to build2.

Where the coverage agrees: everyone says single-tool governance is insufficient, and everyone describes the stack in layers. Where it diverges: which layer is load-bearing — the gateway, the agent runtime, the PR boundary, or the platform. My reading is that the runtime layer is the one that matters most now, because artifact-boundary evaluation cannot distinguish agent-authored from human-authored code, and that distinction is exactly what the new approval authority makes consequential315.

The security undertow

Any evaluation framework built this month has to account for the fact that the agents being governed are themselves attack surface. Researchers disclosed a zero-click remote code execution vulnerability — a plugin SHA-pinning bypass — affecting Claude Code, Codex, GitHub Copilot, and Gemini CLI, giving an attacker reach comparable to the employee running the agent; Anthropic patched Claude Code in 2.1.179 and OpenAI patched Codex in 0.146.0, while Microsoft had not shipped a Copilot fix at the time of reporting1820. A governance layer that enforces policy on code the agent writes while the agent itself runs unpatched is guarding the wrong door. Separately, CrowdSec's confirmation that its source code was stolen in a supply chain attack is a fresh reminder that code provenance and integrity checking belong inside the governance perimeter, not adjacent to it29.

The evaluation that actually works

Synthesizing the Copilot news with the governance coverage, a defensible layered evaluation has four tiers. First, identity and attribution: can the tool distinguish agent-authored from human-authored changes, record authoring context and session-level actions, and survive the artifact-gate problem3? Second, enforcement: are policies deterministic and traceable at the boundary, or advisory — and critically, does the tool allow an AI approval to satisfy a required-approval rule, closing the review loop without an independent human gate15471? Third, evidence: what audit trail exists for decisions and dismissals, and does it map to the documentation and logging duties that regulations now demand212? Fourth, and last, measurement: what do the divergent benchmark numbers actually say, given that vendor-reported catch rates and independent tests disagree by tens of points13?

The uncomfortable conclusion is that the September approval change inverts the usual evaluation order. Teams that treated accuracy benchmarks as the primary criterion are now choosing whether a bot counts as a reviewer — a governance decision with no benchmark at all. The vendors are converging on layered stacks because the problem is genuinely layered, but the layer that changed this month is enforcement, and GitHub just demonstrated that a vendor can move it unilaterally. Evaluating AI code governance tools in 2026 is less about which tool is smartest and more about which one keeps a human — and a patched, accountable agent — on the right side of the merge button.