GitHub Let Copilot Approve Pull Requests. Treat It Like a New Privileged Identity

GitHub Copilot code review can now approve pull requests—and, when administrators opt in, its approval can satisfy a repository’s required-approval rule. The obvious reading is that GitHub gave its AI reviewer a green checkmark. The more useful reading is that GitHub added a new privileged identity to the software-delivery control plane.

That distinction should shape the rollout. A review comment is advice. A counted approval changes repository state: it can remove a branch-protection blocker and move code closer to production. The model’s bug-finding ability still matters, but it is no longer the whole question. Teams now have to govern where this identity has authority, which evidence backs its decision, and which human or deterministic controls remain independent.

GitHub has not claimed that Copilot is equivalent to a human reviewer. It has not published the approval model, decision threshold, approval rate, or false-approval rate. What it has shipped is a deliberately separated path from signal to authority: every Copilot review includes a non-binding assessment; formal approval is off by default; and allowing that approval to count is a separate setting.

That separation makes the public preview unusually useful. Start with the assessment as a shadow signal. Compare it with human decisions. Then grant counted approval only to narrow, reversible change classes that have earned it. Protect the files that configure Copilot itself, retain deterministic checks for artifacts the reviewer does not inspect, and keep a human identity in the path for consequential code.

The trust boundary is no longer “the model.” It now includes rulesets, review instructions, MCP tools, excluded files, billing limits, runner availability, and the exact commit Copilot saw.

RohitAI’s thesis: Copilot did not become a human reviewer. It became an eligible ruleset identity. Treat enabling it like granting a service account a new production permission.

The release creates three different kinds of “approval”

GitHub’s September 1 announcement describes three states that are easy to collapse into one. They are materially different:

The configuration documentation confirms controls at enterprise, organization, and repository levels. Repository administrators can separately allow Copilot to approve and allow those approvals to count. They can also specify up to 15 file globs. A Copilot approval counts only when every changed file matches at least one configured glob; leaving the list blank applies the policy to all files.

That all-files condition is the strongest containment primitive in the release. A pull request with eleven low-risk documentation files and one authentication change can be forced back onto the human path. The glob list should behave like a compiler for permitted change classes, not a broad directory convenience.

GitHub moved the policy boundary, not the evidence bar

Copilot already operates at enormous scale. GitHub reported in March that it had completed 60 million reviews, represented more than one in five code reviews on GitHub, produced actionable feedback in 71% of reviews, averaged 5.1 comments per review, and ran automatically on every pull request at more than 12,000 organizations. Those are GitHub’s own production metrics, not an independent audit.

The figures show adoption and comment usefulness. They do not establish safe approval. Approval is an asymmetric classification problem: an unnecessary “not ready” costs review time, while a false approval on identity, payments, infrastructure, or a data migration can become an incident. Comments per review and thumbs-up rates are the wrong north-star metrics once the output can remove a merge gate.

useful comments ≠ calibrated approval
comment resolution ≠ correctness
review coverage ≠ authority to merge

The missing launch metric is precision among approvals, broken down by language, pull-request size, change class, and risk. Until GitHub publishes that evidence, each organization enabling counted approval becomes responsible for measuring it locally.

The safest feature is the shadow mode GitHub already built

Most AI rollouts force a crude choice between disabled and live. GitHub’s assessment layer creates a better deployment path: collect Copilot’s ready-or-not judgment on real pull requests while keeping it unable to remove a merge blocker. That is not a demo mode. It is the evaluation dataset teams need before delegating authority.

What to measure before a single approval counts

• The exact commit SHA, changed path class, pull-request size, and author type.

• Copilot’s ready or not-ready assessment and the review effort level used.

• The eventual human decision, review comments, and whether the human saw Copilot’s assessment first.

• Any decision change after a later push, rebase, base-branch update, or merge-queue refresh.

• Post-merge reverts, escaped defects, incidents, emergency patches, and ownership escalations.

• Whether agentic tools, MCP context, and runners were available or the review fell back to a limited mode.

Do not optimize for agreement alone. A reviewer that always says “not ready” may agree with cautious humans and still add little throughput. A reviewer that approves almost everything may look efficient until the first expensive miss. Measure approval precision and the cost of misses inside each change class.

This is the first non-obvious advantage of the launch: GitHub has supplied a built-in shadow-deployment path. Teams do not need to debate whether AI review is trustworthy in the abstract. They can ask whether a particular reviewer configuration has earned a particular permission over a measured class of changes.

Protect the reviewer’s instruction plane

The most consequential implementation detail is below the approval UI. GitHub’s code-review documentation says Copilot reads repository custom instructions, agent instructions, and agent skills from the pull request’s head branch, not the protected base branch. That is convenient for testing instruction changes. Once approvals can count, it also means a contributor may change both the artifact under review and part of the reviewer’s operating context in the same pull request.

This does not prove an exploitable bypass, and GitHub does not claim that it does. It does mean the reviewer-configuration surface belongs in the approval threat model. The same untrusted change should not be able to redefine the reviewer and rely on that reviewer as its only counted approver.

.github/copilot-instructions.md
.github/instructions/**
AGENTS.md
.github/skills/**
.github/workflows/**
CODEOWNERS
repository MCP configuration

Put these paths behind CODEOWNERS or a required team, and keep them outside any Copilot-counted allowlist. Copilot code review can also use repository MCP servers; GitHub says the GitHub and Playwright MCP servers are enabled by default and that repository MCP settings are shared with the cloud agent. Tool use and session attributions therefore belong in the audit record for any consequential approval.

This extends RohitAI’s earlier point about portable Copilot agent plugins: skills can travel more easily than trust. A portable instruction or tool surface becomes more sensitive when its output can satisfy a native governance rule.

Practical rule: no pull request that changes the reviewer, its tools, its ownership policy, or its CI authority should be eligible for the reviewer’s only counted approval.

Use the glob rule as a change-class compiler

Repository-level path globs are safer than they first appear because eligibility is conjunctive: every changed file must match. That lets teams make a mixed-risk pull request fail back to people without teaching an AI model a new policy. The useful design unit is not “repository enabled.” It is “change class eligible under these independent gates.”

Treat this table as a starting policy, not universal truth. A documentation repository may consider content changes consequential; a generated test fixture may be harmless elsewhere. The key is to name the class, assign an owner, define the backstops, and promote it only after measured performance.

An approval does not mean every changed byte was reviewed

GitHub excludes many file types and paths from Copilot code review, including common lockfiles, logs, SVGs, minified JavaScript, and content under directories such as dist, vendor, and generated. The documentation says excluded files are not considered during review.

Those exclusions can reduce noise and cost. They also become governance blind spots when an approval has authority. A lockfile can alter a dependency graph. Generated infrastructure output can expose a dangerous plan. A configuration file can change build behavior. “Copilot approved” must not become shorthand for “every changed byte received equivalent scrutiny.”

Keep independent, deterministic gates for excluded and high-impact artifacts:

• Dependency review and lockfile consistency checks.

• CodeQL or another static analyzer, plus secret scanning.

• Policy-as-code for infrastructure, workflows, and release configuration.

• Required tests, migration checks, and coverage thresholds.

• Signed build provenance and artifact verification where the supply chain warrants it.

• Human ownership for identity, authorization, payments, production data, security controls, and deployment authority.

This is the second non-obvious consequence: a review exclusion that was merely a coverage limitation becomes a policy blind spot when the output can satisfy an approval gate. The right response is not to demand that one probabilistic reviewer inspect everything. It is to compose the reviewer with controls suited to each artifact.

Audit the decision like a build attestation

GitHub exposes Lite and Balanced effort levels, but selects the underlying review model automatically. Users cannot switch it, the model is not disclosed, and the reviewer may use models that are not enabled in an organization’s Copilot Chat model settings. A repository can therefore preserve the same ruleset while the effective reviewing system changes underneath it.

The right mental model is a managed service, not a permanent employee whose judgment is stable. A counted decision needs evidence closer to a build attestation:

repository + pull request
exact commit SHA
approval assessment + formal review event
review effort level
policy snapshot + eligible path globs
files considered + known exclusions
review session + MCP/skill attributions
runner and tool availability
dismissal or replacement event

GitHub already exposes parts of this record, including effort level and review-session details. What is missing is a clear reviewer-system revision, the approval threshold, and a first-class exportable attestation. RohitAI’s read is that GitHub will have to add richer evidence as regulated teams ask why a machine identity was allowed to remove a change-control gate.

This is the third non-obvious insight: GitHub’s moat is not only comment quality. GitHub owns the identity, review event, ruleset, protected branch, merge queue, audit surface, billing, and UI that converts judgment into state. Competing reviewers can write clever comments; the platform owner can turn a probabilistic judgment into a native governance primitive.

Cost controls can become merge-availability controls

Copilot code review consumes AI credits for model work and GitHub Actions minutes for agentic context gathering and tools. GitHub estimates a typical Lite review at $0.05 to $1 in AI credits and a Balanced review at $0.25 to $5, excluding Actions minutes. Its current documentation also says reviews are blocked when applicable user, cost-center, or enterprise budgets are exhausted.

That creates a quiet operational coupling. If a team informally replaces an on-call reviewer with Copilot, a finance limit can become a merge outage. If GitHub-hosted runners are disabled and no self-hosted runner is configured, GitHub says a review can still run but without the additional agentic capabilities. The interface may look familiar while the evidence available to the reviewer has changed.

Run failure drills before granting authority

1. Exhaust a test AI-credit budget and observe whether assessment, review, and approval fail closed.

2. Disable the relevant runner path and compare a full agentic review with the documented limited fallback.

3. Push a new commit, rebase, and update through the merge queue; verify stale approval dismissal every time.

4. Confirm an authorized human can restore liveness without bypassing branch protection.

5. Alert on missing review evidence, not just on a missing green check.

A budget is normally a cost policy. Once a paid reviewer becomes part of the approval path, it is also an availability policy. Put its failure mode in the same runbook as CI and identity-provider outages.

AI reviewing AI is the larger platform story

The approval launch is easier to understand beside GitHub’s August 27 expansion. Five days before granting approval authority, GitHub removed the previous 300-file or 20,000-line review limit and enabled full automatic agentic review of bot-authored pull requests, including pull requests opened by Copilot cloud agent. First the platform widened review scope; then it made the reviewer eligible to satisfy an approval count.

That sequence points toward repository-scale AI-on-AI production. It does not mean Copilot can merge its own work. GitHub’s current cloud-agent safeguards still say Copilot-created pull requests require human review, that the agent cannot approve or merge its own pull request, and that pull requests opened under the app identity receive an additional approval requirement when the repository already requires at least one. The September announcement does not say those protections were removed.

Teams should nevertheless define reviewer independence explicitly. Two approvals are not automatically two independent opinions when the authoring and reviewing agents share a vendor, model family, instructions, retrieval context, or failure mode. A future ruleset should distinguish people, first-party agents, and third-party apps—and let organizations require at least one human approval without reconstructing that policy indirectly.

The independent evidence says “evaluate,” not “reject”

No independent study located for this article evaluates the September approval decision or supplies its false-approval rate. That gap should be stated plainly rather than filled with older benchmarks.

A peer-reviewed 2026 study tested an earlier Copilot code-review configuration across seven deliberately vulnerable datasets. It reported fewer than 20 comments and misses on critical examples including SQL injection, cross-site scripting, and insecure deserialization. The experiment predates Copilot’s March 2026 agentic architecture, so it is cautionary context—not the current reviewer’s security recall.

A July 2026 preprint analyzed 54,791 agent-generated review comments across 342 Python repositories. Incorrect suggestions and intentional design decisions were the most common patterns among the sampled unresolved discussions. Comment resolution still does not establish correctness, and comment behavior is not approval precision.

An ESEM 2026-accepted study identified 248,641 AI-attributed pull requests with at least one AI-attributed review and documented rapid growth in AI-to-AI review. It measures prevalence, not safety. Together, these studies justify a cautious evaluation design. None proves the new approval feature safe, unsafe, or equivalent to a human reviewer.

A sensible 90-day rollout

1. Enable non-binding assessments wherever Copilot code review is already approved, but change no merge rules yet.

2. Define low-, medium-, and high-risk change classes with named owners and explicit independent gates.

3. Collect several weeks of shadow decisions, measuring false approvals, not only agreement or useful comments.

4. Select a small repository cohort and allow counted approval only for narrow, reversible paths with strong evidence.

5. Make every mixed-risk pull request fall back to a human by using the all-files glob behavior deliberately.

6. Keep human-only approval for consequential code, reviewer configuration, and AI-authored pull requests.

7. Review results at 30, 60, and 90 days; expand by path class only when evidence, incidents, and audit completeness justify it.

Publish an owner, rollback trigger, and escalation path before the pilot. Roll back counted approval after a material false approval, repeated missing evidence, unexpected specialized-rule behavior, or a failure mode that pressures developers to bypass branch protection. Public preview should mean reversible experimentation, not organization-wide optimism.

Frequently asked questions

Can Copilot now merge its own pull requests?

No such capability was announced. Copilot code review can submit an approval that may satisfy an ordinary required-approval rule. GitHub’s separate cloud-agent documentation still says Copilot-created pull requests require human review and that the cloud agent cannot approve or merge its own pull request. Verify the interaction with your exact ruleset during the preview.

Is Copilot approval enabled by default?

No. Approval authority is off by default. Letting a Copilot approval count toward merge requirements is a separate repository choice, and enterprise or organization policy can prevent lower levels from enabling it.

Can counted approvals be limited to low-risk files?

Yes. Repository administrators can configure up to 15 globs, and every changed file must match at least one for Copilot’s approval to count. A blank list applies to all files. Use narrow allowlists and test negative and mixed-path cases.

Does GitHub publish Copilot’s false-approval rate?

Not in the launch sources. GitHub publishes adoption, feedback, comment-volume, cost, and latency information, but not the approval model, threshold, approval rate, or false-approval rate by language, pull-request size, or risk class.

What happens after a new commit?

GitHub says a new push dismisses Copilot’s approval and allows a fresh review. Test pushes, rebases, force pushes, stacked pull requests, base-branch changes, and merge-queue updates in your repository because the launch documentation does not answer every specialized ruleset interaction.

Final take

GitHub has given engineering teams two genuinely useful controls: observe an AI approval judgment before it has authority, and constrain that authority by path. Use both.

The mistake is to interpret a counted approval as evidence that AI review has reached human equivalence. GitHub has not made that claim, and the published evidence does not support it. The better conclusion is that software delivery now has a new privileged identity—one that may be fast, useful, and scalable, but whose instructions, tools, evidence, availability, and scope must be governed.

Trust should expand by measured change class, independent backstop, and reversible policy—not by repository-wide faith in a green check. Copilot’s approval should be earned one permission at a time.