copilot approvals need separation of duties

GitHub shipped one of those changelog entries that looks small until you read it like an engineer responsible for production.

Copilot code review can now approve pull requests.

Not just comment. Not just summarize. Not just say “this looks ready” in a friendly overview paragraph.

Approve.

That is a different verb.

A review comment is advice. An approval is part of the merge protocol. It interacts with branch protection, ownership rules, audit logs, deployment gates, CI trust, package publishing, and the boring little controls that keep a software organization from becoming a vibes-based merge machine.

So the question is not “should AI be allowed to review code?”

That question is already stale.

The better question is: when an AI review is allowed to count, what duties must it be separated from?

approval is not just better review UX

I like AI code review in the same way I like linters, static analysis, dependency alerts, and good test output. The best version reduces noise and catches the obvious stuff before a human wastes attention on it.

Copilot approval assessments are useful in that world. If the tool reviews a pull request and says it thinks the change is ready, that can be a signal. Maybe it found no blocking issues. Maybe it saw only low-risk edits. Maybe it gives the human reviewer a faster way to triage the queue.

Fine.

But the moment the approval can count toward required approvals, it is no longer just a signal.

It becomes one of the things that can move code from “proposed” to “mergeable.”

That changes the threat model.

Teams have spent years teaching developers that the merge button is not just a button. It is a controlled boundary. We put rules around it because code review is not only about code quality. It is also about accountability.

Who looked at this?

Who had enough context to accept the risk?

Which automated checks passed?

Which paths changed?

Was the person approving independent from the person making the change?

If Copilot can now participate in that protocol, it needs to be governed like a participant in that protocol. Treating it as “another reviewer” is lazy architecture.

It is a new merge primitive.

the useful version is narrow

The useful version of Copilot approvals is not hard to imagine.

There are pull requests where a machine approval is probably acceptable, or at least acceptable as one part of the evidence.

Generated documentation. Test fixture updates. Formatting-only changes. Mechanical refactors where the compiler, tests, and ownership rules give strong evidence. Maybe low-risk generated code in a repository where the generation process itself is controlled and reproducible.

For those changes, an AI approval could reduce human review drag. Nobody should have to spend senior-engineer attention rubber-stamping a thousand-line generated diff that a deterministic tool produced and CI already validated.

But that is the key phrase: as one part of the evidence.

The dangerous version is broader.

An agent writes a change. Another agent, or the same class of tool wearing a different hat, reviews it. CI passes because the test suite is weak or because the change altered the workflow that runs the tests. The approval counts. The merge button lights up. Everyone gets to pretend there was independent review.

That is not separation of duties.

That is automation laundering.

some paths should be human-only

The first policy should be boring and explicit:

Copilot approvals should not count for sensitive paths.

I would start with a denylist that includes:

• deployment workflows
• authentication and authorization code
• payments and billing code
• ledger, reconciliation, and money-movement logic
• secrets handling
• CI and release automation
• dependency manifests and lockfiles
• infrastructure as code
• package publishing configuration
• production incident tooling
• security policy and code scanning configuration

This is not because Copilot is useless in those areas. It may be very useful there.

It can still comment. It can still explain. It can still point out suspicious patterns. It can still help the human reviewer ask better questions.

But its approval should not satisfy the merge rule.

There is a difference between using a tool to improve judgment and delegating the control decision to that tool.

Sensitive paths are where that distinction matters most.

If a pull request changes a GitHub Actions workflow, I do not want the same platform that will execute that workflow to be treated as an independent approver of the change. If a pull request changes authentication behavior, I do not want a generic “looks good” from an AI reviewer to count as a security sign-off. If a pull request changes package publishing, I want the approval path to be as boring and traceable as the release path.

The point is not fear of AI.

The point is that critical controls should not be collapsed into one convenient product surface.

context exclusions matter more now

There is another uncomfortable detail: agents do not always see everything.

GitHub also made content exclusions generally available for Copilot app and CLI. That is good. Enterprises need a way to keep sensitive files out of agent context.

But if an agent is allowed to approve code, the exclusion policy becomes part of the approval policy.

An approval from a reviewer who was not allowed to read the relevant files is weaker evidence.

That sounds obvious when stated plainly, but I expect many organizations to miss it. They will configure content exclusions for privacy or data-boundary reasons, then later enable AI approvals as if the reviewer had normal repository visibility.

That is not how review works.

Imagine a human reviewer saying: “I approve this auth refactor, but I was not allowed to open the policy files, the integration tests, or the deployment workflow.”

You would not count that as a strong review.

The same standard should apply to the agent.

Approval policy needs to know not only which files changed, but also which files the tool was allowed to inspect while forming the approval. For low-risk generated docs, maybe that does not matter much. For a service boundary, it matters a lot.

CI is not automatically independent

The easy answer is to say: let Copilot approve only when CI passes.

That is necessary.

It is not sufficient.

CI is only independent evidence when the pull request cannot cheaply compromise the checks that are supposed to constrain it.

If the change edits workflow files, reusable workflow references, build scripts, dependency installation, test selection, or artifact publishing, then the CI result is part of the thing being changed. You need a stronger review path.

This is why the nearby GitHub Actions and CodeQL changes are relevant. GitHub has been tightening the trust boundary around Actions: more precise CodeQL detection for GitHub Actions issues, clearer reusable workflow identity context, least-privilege permissions, and read-only cache tokens for untrusted triggers.

That is the right mental model.

Automation is not a blob of trust. It has boundaries.

An AI approval should inherit those boundaries, not float above them.

If the diff changes the machinery that produces the green check, then “green check plus AI approval” is not enough. The reviewer needs evidence that the check still means what everyone thinks it means.

agent-authored code needs independent review

Here is the rule I would make non-negotiable:

An agent should not be allowed to approve a pull request that was primarily authored by the same class of agent.

I am not saying every AI-assisted pull request needs a committee. That would be silly. Developers already use autocomplete, chat, and refactoring tools all day.

The interesting case is a pull request where the agent did the substantive work: planned the change, edited the files, wrote the tests, and opened the PR.

In that case, an AI approval from the same product family should not count as independent review.

Maybe a human can approve it. Maybe a different automated control can provide evidence. Maybe a deterministic generator plus reproducible build plus strong tests is enough for a narrow path. But “agent wrote it, agent approved it” should not satisfy separation of duties.

This sounds strict until you translate it back into human terms.

We usually do not let authors be their own independent reviewers. We do not treat a developer saying “I checked my own work” as the same thing as another qualified person reviewing it.

AI does not make that principle obsolete. It makes it easier to accidentally violate.

the policy ladder

I would not start by enabling AI approvals everywhere and hoping repository admins figure it out later.

I would use a ladder.

At the bottom: approval assessments only.

Let Copilot say whether it thinks the pull request is ready. Do not let that count toward required approvals. Watch the quality of the signal. See where it helps. See where it is noisy. Tune the instructions and review effort.

Next: allow counted approvals only on explicitly low-risk paths.

Examples: documentation, generated examples, formatting-only changes, test-only changes, fixture updates, and mechanical refactors that have strong CI coverage. Require ownership rules and branch protection to pass. Require the approval to be dismissed on new commits.

Next: require policy evidence.

The approval should be explainable. Which files changed? Which paths were allowed? Which content exclusions applied? Which checks passed? Was the PR human-authored, agent-authored, or mixed? Did any sensitive path rule trigger?

Next: expire exceptions.

Temporary policy exceptions should have expiration dates, just like temporary budgets. A team may need a short-lived allowance during a migration. Fine. But permanent exceptions become folklore. Folklore becomes production risk.

At the top: keep some repositories human-only.

Not every repo needs AI approvals. Authentication platforms, payment systems, ledgers, infrastructure modules, release automation, security tooling, and regulated workloads may still benefit from AI comments without letting the tool count as an approver.

That is not anti-AI.

That is normal engineering judgment.

publishing has the right analogy

The npm trusted publishing changes are a good analogy.

Modern publishing systems are moving away from long-lived tokens and toward OIDC-based workflows, independent configurations, staged publishing, malware scanning, and explicit human approval before release.

That is the pattern: reduce secret sprawl, automate the boring checks, preserve the meaningful gate.

Pull request approvals should move in the same direction.

If AI review becomes part of the merge path, then the policy should be explicit about what the tool can approve, what it can only comment on, and where a human or separate control must remain in the loop.

The mature answer is not “never let AI approve anything.”

The mature answer is “do not confuse convenience with independence.”

the real risk is pretending nothing changed

I expect some people to overreact to AI approvals.

They will say no machine should ever approve a pull request. That is too simple. We already let machines block and unblock changes in many ways. Tests, linters, scanners, policy engines, deployment gates, and generated attestations all participate in software delivery.

The problem is not machine participation.

The problem is unclear authority.

If a linter fails, we know what it means. If CodeQL flags a vulnerability, we know what kind of evidence it provides. If branch protection requires two approvals, we know the human accountability model we intended.

AI approval muddies that unless we define it carefully.

What does it mean for Copilot to approve?

Does it mean the code is correct? No.

Does it mean there are no security issues? No.

Does it mean the tool found no blocking concerns within the context and policy it was allowed to use? That is closer.

And if that is what it means, then the policy needs to say where that kind of evidence is strong enough to count.

My bias is simple: let AI review aggressively, but let it approve conservatively.

Use it to reduce noise. Use it to catch boring mistakes. Use it to summarize risk. Use it to make human review sharper.

But when the approval becomes part of merge control, stop treating it as a productivity feature.

Treat it as a security and governance feature.

Separate the duties. Name the paths. Preserve independence. Keep the audit trail boring.

Agent approvals are not inherently bad.

Pretending they are just another reviewer is.

references

• GitHub Changelog: Copilot code review can now approve pull requests
• GitHub Changelog: Upcoming changes to GitHub Copilot policies and billing
• GitHub Changelog: Content exclusions generally available in Copilot app and CLI
• GitHub Changelog: Set an expiration date for individual user budgets
• GitHub Changelog: CodeQL 2.26.4 improves GitHub actions security detections
• GitHub Changelog: GitHub Actions: Early September 2026 updates
• GitHub Changelog: Read-only Actions cache for untrusted triggers
• GitHub Changelog: Multiple trusted publishing configurations for npm

To test my projects, I use Railway. If you want $20 USD to get started, use this link.