Copilot Can Now Approve Your Pull Requests. Your Auditor Still Thinks a Human Did.

What Did GitHub Actually Ship on 1 September?

GitHub's changelog entry of 1 September 2026 is short and carefully worded. Copilot code review, which until now could only leave comments, can now submit a formal pull request approval, and when an administrator enables it, that approval can count toward the repository's required-approvals rule. The preview is available on Copilot Pro, Pro+, Max, Business and Enterprise plans. By default, as the changelog puts it, "Copilot will not approve pull requests."

Alongside the approval capability, every Copilot review now includes an approval assessment in its overview comment: a signal of whether the model considers the change ready to merge. GitHub is explicit that the assessment on its own does not count toward merge requirements. It only becomes an approval when someone, at every level of the organisation, decides to let it. Settings cascade from enterprise to organisation to repository, and at the repository level admins can restrict which file paths Copilot is allowed to approve. If new commits arrive after Copilot approves, the approval is dismissed, exactly as it would be for a human reviewer.

The reviewer behind that approval also changed within days. According to AI Stack Current, an 11 September update gave Copilot code review the full set of shell tools from the Copilot SDK, so it can run builds, tests and scripts while it reviews, and moved the Lite effort level to an ensemble of agents whose findings are merged. GitHub's own experiments reported more addressed comments per review and a roughly 8% reduction in review cost. And as DevOps.com reported, GitHub had already removed the previous cap of 300 files and 20,000 lines per review in late August and extended coverage to pull requests opened by bots and by Copilot's own cloud agent.

Put those three changes together and the product is no longer a linter with opinions. It is an agent that reads the diff, runs the code, decides whether the change is safe and, if you allow it, signs off. Mitch Ashley of The Futurum Group summed it up for DevOps.com: "Approval is where code review stops being advice and becomes authority, and GitHub just moved Copilot across that line."

Why Is This Arriving Now?

Because human review has become the slowest part of the delivery pipeline, and everyone knows it. BairesDev's Q3 2026 Dev Barometer, reported by IT Brief, surveyed 705 developers in more than 60 countries and found that 42% say AI now writes at least half their code, up from 12% a year earlier. Developers report saving an average of 13 hours a week on coding, but 67% say they spend more time reviewing AI-generated code and 52% spend more time fixing problems AI introduced. Only 21% still spend more than half their week writing new code from scratch.

The money is following the bottleneck. The same survey found that 78% of CTOs increased spending on code review, quality assurance and validation. BairesDev CEO Darren Shimkus put the result bluntly: "Developers nearly doubled the time AI saves them in coding, to 13 hours a week. Not one of those hours came back." We made the same argument from the delivery side in our analysis of coding agent fleets: writing code got cheap, landing it did not.

Seen from a platform vendor's chair, automated approval is the obvious next move. If agents generate the pull requests and humans cannot read them fast enough, let another agent clear the queue. The question engineering leaders have to answer is not whether the model is good at review. It is often quite good. The question is what an approval is for, and whether a model can carry that function.

There is also a quieter data point in the BairesDev numbers. 7% of developers said the decision to ship code had already been fully delegated to AI without human input. That was before the approval feature reached most teams. Automated approval does not create that behaviour. It formalises it and makes it count.

What Is a Pull Request Approval Actually For?

A required review does two jobs that are easy to conflate. The first is defect detection: a second pair of eyes catches bugs, missing tests and bad design. AI review can genuinely help here, and on some classes of problem it is faster and more consistent than a tired human at 6 p.m. The second job is accountability: a named person, independent of the author, attests that the change was examined and accepts a share of responsibility for letting it through.

Almost every control framework your customers and auditors care about leans on the second job. Change management controls in a typical SOC 2 audit are evidenced by showing that changes to production were reviewed and approved by someone other than the person who made them. Banks, insurers and payment companies inherit similar expectations from their regulators and pass them down to suppliers through contracts. The approval record in GitHub is, in practice, the evidence.

PCI DSS is the clearest written example. Requirement 6.2.3.1, as restated in the v4.0.1 control text, says that where manual code reviews are performed on bespoke and custom software, code changes are reviewed by individuals other than the originating code author who are knowledgeable about code-review techniques and secure coding practices, and that results are reviewed and approved by management prior to release. "Individuals" is doing a lot of work in that sentence. A model is a useful tool in that process. It is not an individual, and it cannot be held to account by management.

None of this means AI review fails audits. Automated analysis has always been welcome as an input. What changes on 1 September is that the same checkmark in the same field can now mean either a person or a model, and many evidence pipelines, dashboards and auditors' sampling procedures cannot tell the difference unless you design them to.

Where Does Separation of Duties Break?

The sharpest problem is the closed loop. Copilot's cloud agent can author a pull request, and Copilot code review can now approve one. As a detailed configuration walkthrough on DEV Community points out, that lets the same vendor's models act as both author and reviewer, which is precisely the pattern separation-of-duties controls exist to prevent. Different prompts and different agents do not make the reviewer independent in the sense an auditor means. They share a vendor, a model family and plausibly the same blind spots.

The second problem is that the change can shape its own review. GitHub's code review customisation tutorial states that, when reviewing a pull request, Copilot reads repository custom instructions, agent instructions and agent skills "from the head branch (the branch with your changes), not the base branch." That is convenient for testing new review guidance. It also means a pull request can modify the instructions its reviewer follows. Once that reviewer's approval can unblock a merge, a sentence added to .github/copilot-instructions.md becomes a merge-relevant input. The same walkthrough flags prompt injection as a merge-relevant risk for exactly this reason, and we covered the wider pattern in our piece on attacks against coding agents.

Third, a number of interactions are simply not documented yet. As of mid-September, the same walkthrough could not confirm from GitHub's documentation whether a Copilot approval satisfies the "require approval of the most recent reviewable push" rule, whether it can count as a code owner review, whether it can trigger auto-merge, or whether it satisfies the extra approval rule for Copilot-authored pull requests. It also found no approval-specific audit event, only events for changes to the settings. When the control you are relying on has undocumented edges, you are not relying on a control.

Finally, there is the quality question. Copilot's reviewer may be good, but the code it is reviewing is increasingly machine-written, and that code has a measurable defect profile. CodeRabbit's analysis of 470 open source pull requests found AI-co-authored pull requests carried about 1.7 times as many issues as human-only ones, and The Register reported roughly 10.83 issues per AI pull request against 6.45 for human ones, with XSS vulnerabilities 2.74 times more likely. CodeRabbit sells AI review and acknowledges its classification of AI versus human authorship is imperfect, but the direction matches what most teams see. A model approving another model's output is the case where independent judgment matters most.

Is There a Safe Way to Use AI Approvals?

Yes, and GitHub has given you most of the controls to do it. The useful framing comes from the DevOps.com coverage: teams that enable approvals everywhere at once risk trading a review bottleneck for a governance gap. Start with low-risk paths such as documentation, configuration and test code, then expand only after measuring results.

The mechanics matter. According to the configuration walkthrough, a Copilot approval only counts when every enterprise, organisation and repository setting allows it, the assessment says ready, the file-path filter matches, and no commit has been pushed since. The path filter accepts up to 15 globs, and every changed file in the pull request must match for the approval to count. That is a genuinely useful property: a pull request that touches docs/ and src/auth/ falls back to human review automatically.

Layer CODEOWNERS on top. Require code owner review on infrastructure, authentication, payments, workflow definitions and, critically, on the agent instruction files themselves: .github/copilot-instructions.md, .github/instructions/ and any skills directories. If a pull request changes how the reviewer behaves, a human should approve it. Keep "require approval of the most recent push" on, and keep stale-review dismissal on.

Set the enterprise and organisation policies to allow-lists rather than delegation, so a single repository admin cannot opt a regulated service into AI approval on their own. And keep the approval assessment visible even where counting is off. It is free signal, and comparing its verdicts against your human reviewers' decisions for a month is the cheapest pilot you will ever run.

What Should You Measure Before Trusting It?

GitHub does not ship the dashboard you need. DevOps.com notes that measurement is not built in: tracking correct approvals, post-merge catches by humans and whether approval speed is eroding review depth is work the organisation has to do itself. That is not a reason to avoid the feature. It is a reason to treat adoption as an experiment with a hypothesis and a stopping rule.

Four numbers are enough to start. First, agreement rate: on pull requests where both Copilot and a human reviewed, how often did their verdicts match, and in which direction did they disagree? Second, escape rate: of the changes Copilot approved, how many later produced a revert, a hotfix or an incident? Third, human time recovered: did reviewers actually spend the saved hours on the high-risk queue, or did the hours vanish into more generated pull requests? Fourth, evidence integrity: can your compliance export distinguish AI approvals from human ones for every merged change?

Tag the reviewer identity in your metrics from day one. The walkthrough warns that Copilot-resolved review threads look like human-resolved ones in naive counts, which will flatter your review-health numbers. If you already track change failure rate, segment it by approver type. If AI-approved changes fail at the same rate as human-approved ones on the same paths, widen the scope. If they do not, you have learned something cheaply.

Pair the approval metrics with test-integrity checks. A reviewer that runs the test suite is only as good as the suite, and agents are known to make tests pass in ways that do not make code work, as we described in our article on reward hacking and mutation testing. Mutation testing on the paths where AI approval is allowed is a sensible precondition.

What Do Your Customers and Auditors Need to Hear?

If you build software for regulated customers, assume the question is coming. Security questionnaires already ask whether changes are peer reviewed. The next revision will ask whether the peer can be a model, and "we turned on a GitHub setting" is not an answer a bank's third-party risk team will accept. Write down your policy before someone asks for it: which paths allow AI approval, which require a named human, how instruction files are protected and how you evidence the difference.

For European clients the stakes are rising through the supply chain. Under the frameworks we discussed in our DORA third-party risk article and our NIS2 supply chain piece, financial entities and essential operators are pushing secure-development expectations down to their software suppliers. A supplier whose change approvals are partly automated needs to show that the automation sits inside a control framework, not instead of one.

The same logic applies when the code is shipped as a product. The revised EU Product Liability Directive makes software a product for liability purposes from December 2026. When a defect reaches a customer, "an AI approved it" will not move liability anywhere. It will simply raise the question of why no one with authority looked.

This is where outsourcing arrangements deserve a second look. If your development partner uses AI review, ask whether their AI approvals count toward merge rules on your repositories, who configured that, and whether the approval records they hand you distinguish people from models. Your audit trail is only as clear as the least clear repository in it.

How Stepto Handles AI Review in Client Repositories

At Stepto we use AI review heavily, because the volume of AI-assisted code our dedicated development teams produce demands it. But we treat it as the first reviewer, never the last. In client repositories, AI approvals only count on paths the client has agreed are low risk, typically documentation and test scaffolding, and every change to authentication, payments, data handling, CI workflows or agent instruction files requires approval from a named senior engineer who is listed in CODEOWNERS.

That senior layer is the part that does not scale with tokens, and it is where nearshore teams earn their cost. A reviewer in Belgrade working in the same hours as a team in Berlin, Amsterdam or London can turn around a sensitive review the same afternoon, which removes most of the pressure to let a model approve it instead. For US clients, our overlap with the East Coast morning covers the same need. Faster human review on the risky 20% is what makes it safe to automate the other 80%.

We also hand clients the evidence, not just the code. Approval records that separate human and AI reviewers, the path policy in writing, and a monthly view of agreement and escape rates are part of how our nearshore development engagements report on quality. If you are trying to work out where AI review belongs in your own pipeline, or need a team that already runs this way, talk to us.