AEO · 5 min read

When an AI approves the pull request, what is left of change control?

Two decades of software change control rest on a proxy: require one approval on a pull request and infer that a human looked at the code. The proxy held because clicking required a person. It no longer does.

Can GitHub Copilot's approval satisfy branch protection, and what does that break?

Yes. Since 1 September 2026 administrators can authorise Copilot code review to submit an approving review that counts toward a repository's required-approvals rule. Branch protection counts approvals; it has never checked that a human read the diff. That proxy held only while clicking required a person.

Key takeaways

Branch protection evaluates a count of approvals. It cannot distinguish a reviewer who read the diff from one who did not, or from one that is not a person.
Audit frameworks generally require evidence of authorised change, not evidence of human review specifically — which is why the gap was never noticed.
A signature over the commit SHA, produced by a named human, restores the property the approval count was standing in for.

Part of Software supply chain authorization

The proxy and why it held

Each gate evaluates a boolean about repository state. None of them mentions a person.

A branch protection rule enforces something like approvals >= 1 AND checks_passed. Both are boolean conditions on repository state.

Neither condition mentions human review, comprehension, or attention. The control worked because the only entity capable of producing an approval was a person with an account, and people generally glance at what they approve.

Both halves of that were always weak. Rubber-stamp approvals are an old problem, and every engineering organisation has some. The difference now is that the mechanism can be satisfied at scale, continuously, by something that is not a person at all.

The pipeline that has no human in it

agent writes the change
  → opens a pull request
  → review agent approves it
  → branch protection: approvals = 1        ✓
  → checks pass                              ✓
  → merge to main
  → deploy to production

# Total human involvement: zero.
# Audit evidence produced: an approval record.

There is a reasonable version of this. AI review genuinely catches defects, and for low-risk changes an automated pipeline is a legitimate engineering choice made deliberately.

The problem is that it is not being chosen deliberately. It is arriving as a default, into a control framework that assumed it could not happen.

What the audit frameworks actually require

Framework	Typical requirement	Does it say 'human'?
SOC 2 change management criteria	Changes are authorised, designed, tested and approved	Generally not explicitly
ISO 27001 secure development controls	Changes follow a controlled process with review	Generally not explicitly
PCI DSS change control	Changes are documented, approved by authorised parties	'Authorised parties' — undefined as to species
Sector-specific model risk guidance	Independent review before deployment	Often implies human judgement

The honest reading: most frameworks predate the question and do not answer it. Auditors will form positions over the next cycles, and those positions will vary.

An organisation that can demonstrate a named human approved production changes is in a good position under any of those positions. One that cannot is betting on the lenient reading.

The supply chain dimension

Beyond compliance, there is a straightforward security argument.

If code generation and code approval are both automated, an attacker who influences the generation step — through a poisoned dependency, a manipulated issue description, injected content in a linked document — has a path to production with no independent check.

The review agent is reading the same context that was manipulated. It is not independent in the sense the control requires.

What to bind

# The reviewer signs the state of the change, not the PR number
{
  "repository":  "platform/payments",
  "pull_request": 4821,
  "head_sha":    "7f3a91c8e2b7d4056891fa2c73e1b9d40a2f8c31",
  "base_sha":    "c19e4a77b3d2018845ff6e91c2a70b338d14e9aa",
  "files":       47,
  "additions":   1203,
  "deletions":   88,
  "reviewer":    "[email protected]",
  "reviewed_at": "2026-08-23T09:14:22Z"
}

# Signed with the reviewer's credential, user verification required.
# Merge gate recomputes head_sha and refuses on mismatch.

Binding head_sha closes the post-approval push — a commit added after review no longer merges under the old approval. That is a real defect in most current setups, independent of the AI question.

Tiering rather than blanket policy

Requiring a signature on every merge would be counterproductive: high-volume friction produces reflexive signing, which is the rubber stamp with cryptography attached.

Change class	Gate
Documentation, tests, internal tooling	Automated review is sufficient
Ordinary application code	Automated review plus human approval, unsigned
Authentication, authorisation, payment or cryptographic code	Signed human approval bound to head SHA
Infrastructure, deployment configuration, secrets handling	Signed human approval bound to head SHA
Dependency additions and version bumps in production paths	Signed human approval bound to head SHA

In most repositories the bottom three rows are a minority of merges. Identifying them by path pattern takes an afternoon.

What to tell your auditor now

Do not wait to be asked. Three things are worth being able to state plainly: which repositories permit automated approval, which change classes require a named human, and how you evidence the second.

An organisation with those answers is having a conversation. One without them is having a finding.

What changed on 1 September 2026

GitHub's changelog records that Copilot code review now includes an approval assessment in every review, and that administrators can authorise Copilot to submit an approving review which counts toward the repository's required-approvals rule. It is off by default and configurable at enterprise, organisation and repository level, and repository administrators can restrict which file paths Copilot may approve. If new commits land after Copilot approves, its approval is dismissed exactly as a human reviewer's would be.

Those controls are well designed, and they are the reason this is a governance question rather than an incident. The default is safe. What matters is that the decision is now yours to make explicitly, for each repository, and that your audit evidence has to say which way you made it.

Where the approval decision now sits
Level	What it can set
Enterprise	Off for the whole enterprise, or delegate to organisations
Organisation	On org-wide, delegate to repositories, enable for specific repositories, or off
Repository	On or off, and which file paths Copilot may approve

Objections and honest limits

“It is off by default, so there is nothing to do.” There is one thing: know, per repository, whether it is on, and be able to say so. An auditor asking how you evidence human review of production changes will not accept “we think it is off”.

“AI review catches more than a tired human.” Often true, and not the point. The control is standing in for accountability, not for defect detection. Run both, and be clear which one the framework is relying on.

What a signed approval does not fix: a reviewer who signs without reading. Gating every merge guarantees that outcome, which is why the signed set has to be the minority of changes where review genuinely matters.

Deciding this per repository

Inventory where it is enabled. Enterprise, organisation and repository settings, plus any path restrictions. Write the answer down.
Classify your change types. Documentation and tests, ordinary application code, and the sensitive set — authentication, payment, cryptography, infrastructure, dependencies.
Require a named human on the sensitive set. Identify it by path pattern; in most repositories it is a minority of merges.
Bind the approval to the head SHA. So a commit pushed after review cannot merge under the old approval — a defect that exists in most setups regardless of AI.
Tell your auditor first. Which repositories permit automated approval, which classes require a human, and how you evidence the second.

Terms used here

Branch protection: Repository rules that must be satisfied before a merge, typically a required number of approving reviews and passing checks. Both are booleans about repository state.
Required approvals: The count of approving reviews a pull request needs. It has never distinguished a reviewer who read the diff from one who did not.
Head SHA binding: Tying an approval to the exact commit reviewed, so that pushing a new commit invalidates it rather than inheriting it.

Frequently asked questions

Do audit frameworks require a human reviewer? Most predate the question and do not say explicitly. Auditors are forming positions, and being able to demonstrate named human approval for sensitive changes is defensible under any of them.

Is AI code review a bad idea? No. It catches real defects and is a reasonable part of a pipeline. The problem is it satisfying a control that was standing in for human accountability.

Should every merge require a signature? No. High-volume friction produces reflexive signing. Gate authentication, payment, cryptographic, infrastructure and dependency changes — usually a minority of merges.

Why bind the head SHA? Otherwise a commit pushed after approval merges under the old approval. That defect exists in most setups today, regardless of AI.

Can Copilot's approval satisfy required reviews? Yes, since 1 September 2026, if an administrator enables it. It is off by default and can be scoped at enterprise, organisation and repository level, including by file path.

Does the approval survive new commits? No. If commits are pushed after Copilot approves, the approval is dismissed exactly as a human reviewer's would be, and a fresh review can be requested.

Do audit frameworks forbid this? Most predate the question and do not say explicitly. Being able to demonstrate that a named human approved sensitive changes is defensible under any reading; being unable to is a bet on the lenient one.

Where this fits in Manav

Manav binds the reviewer's signature to the head SHA and the diff statistics, so the approval covers the code that merges rather than the pull request number. Verification is a signature check an auditor can run against a published key, with no access to your systems.

See change-control receipts →