Risk-Gated AI Pull Request Approval with Copilot

Code review has always been a little slow (if you’ve ever watched a one-line fix sit in a queue for three days, you know what I mean). Someone opens a pull request, a teammate gets to it when they can, and the change waits in between. That was tolerable when a developer opened a few pull requests a week. With AI coding tools, the same developer can open several a day, and the number of people qualified to review them hasn’t changed.

The data backs this up. Faros AI found that teams with high AI adoption merged 98% more pull requests, while review time rose 91% and pull requests got 154% larger⁹. LinearB found that agent-generated pull requests wait about five times as long for a reviewer to pick them up^4,5. Teams are writing code faster and shipping it at about the same pace, because the extra work piles up in the review queue^2,8.

One idea that keeps coming up is AI pull request approval: have AI grade each pull request for risk, using the organization’s own regulatory and industry rules, and approve the low-risk ones automatically. Senior engineers then spend their review time on the changes that need their judgment. Intercom, Ona, Rewind and Anthropic all run versions of this today^{34,35,36,37,39}.

I think risk-based approval is worth doing, but I’d keep the actual approval decision out of Copilot’s hands. Its findings should feed a set of deterministic rules, and those rules should decide. In this post I work through a design I recently reviewed. GitHub Copilot code review checks each pull request, a webhook calls an Azure Function, and the Function approves the low-risk ones in Azure DevOps or GitHub.

As of October 2026, Copilot code review can’t call a webhook or return a machine-readable risk grade, and on Azure Repos it can’t approve a pull request at all^18,25. The Function has to compute the grade itself from deterministic signals, treat Copilot’s review as one untrusted input, tie its decision to the exact commit that was reviewed, and leave sensitive code paths and compliance-scoped repositories to people.

Most of the Copilot features involved are in public preview, and several changed between June and October 2026, so treat the platform details here as a snapshot of where things stood in mid-October.

In this post, you’ll learn:

• Why review, not coding, is now the bottleneck, with data from Faros AI, LinearB and DORA
• What GitHub Copilot code review can and can’t do on GitHub and Azure Repos as of October 2026
• What Intercom, Ona, Rewind and Anthropic learned from letting AI approve pull requests, and how much review you can realistically hand off
• The security risks of an AI approver, and a reference design for risk-gated approval using an Azure Function
• How to get compliance sign-off for SOC 2, PCI and SOX, plus a phased rollout plan

The Review Bottleneck in Numbers

The most-cited numbers come from Faros AI’s 2025 AI Productivity Paradox report, based on telemetry from more than 10,000 developers across 1,255 teams⁹. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. Over the same period, pull request size grew 154%, review time rose 91%, and bugs per developer rose 9%. Delivery metrics at the company level stayed flat³. Faros’s 2026 AI Engineering Report, covering 22,000 developers, puts the increase in median time in review at 441%, and reports a 31% increase in pull requests merged with no review at all, human or agentic. (That’s a 31% increase in the rate, not 31% of all pull requests. Some secondary sites also credit the 441% figure to the DORA report, but it comes from Faros.)

LinearB’s 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 teams in 42 countries, show where the time goes⁴.

Once a reviewer opens an AI-assisted pull request, they finish it faster than an unassisted one (3.2 hours against 4.2). LinearB sums that up as “the largest changes receive the least review time.”⁴ Waiting for a reviewer is the constraint, more than reading the diff. A tool that helps people read diffs faster won’t help much if the pull request sits for a day before anyone opens it.

Google’s DORA 2025 report, with nearly 5,000 respondents, found that 90% of developers now use AI, up 14% from the year before, and more than 80% say it makes them more productive. About 30% trust AI output “a little or not at all,” and AI adoption still correlates with lower delivery stability^1,6,7. Sonar’s January 2026 survey of more than 1,100 developers found that 38% of them find reviewing AI-generated code harder than reviewing a colleague’s.

The failure mode I worry about most is rubber-stamping. Intercom describes the choice plainly: when review can’t keep up, “either the queue backs up and velocity drops, or, more dangerously, humans start rubber-stamping.”³⁴ A 2026 study by Duma et al. of 33,596 agent-authored pull requests in popular open-source repositories found that 61.38% had no recorded review activity, though the authors caution that this “does not imply the absence of human oversight.”¹⁰ That’s the failure mode auditors should worry about too, because the change-management control still shows up in the SOC 2 evidence even when nobody is really performing it⁴⁸.

What GitHub Copilot Code Review Can and Can’t Do in October 2026

On GitHub, Copilot can approve a pull request if an admin allows it^12,18. On Azure Repos, it can’t approve anything²⁵, and that one difference shapes most of the design that follows. (If you’re new to Copilot reviews, we covered the basics in Using GitHub Copilot for Pull Request Reviews.)

Copilot Code Review on GitHub

Automatic reviews are set up through branch rulesets, with options to review new pushes and to choose an effort level¹³. Since October 2, 2026, reviews can also be requested through the REST and GraphQL APIs, and Balanced is the default effort level¹⁹. Teams can steer the reviewer with .github/copilot-instructions.md for repository-wide rules, path-specific .instructions.md files with applyTo globs, files such as AGENTS.md, agent skills, and repository MCP servers¹⁶.

Since the July 17, 2026 changelog, Copilot reads custom instructions, agent instructions and skills from the pull request’s head branch instead of the base branch¹⁷. To be fair, that makes sense for a developer tuning their own review instructions. For a gate, though, it’s a problem. A pull request that edits copilot-instructions.md is reviewed under its own edited rules, so an author, or an agent that has been prompt-injected, could add a line telling the reviewer to treat changes under /auth as low risk. If you use Copilot as any part of a gate on GitHub, put the instruction files under CODEOWNERS and have the gate treat any change to them as high risk automatically⁴⁵.

Approvals arrived in public preview on September 1, 2026. Every review now includes an “approval assessment” in its overview comment, and GitHub is clear that “an approval assessment alone does not count toward merge requirements.”¹⁸ Admins can let Copilot submit approvals that do count, at the enterprise, organization or repository level. That setting is off by default. Repository admins can limit approvals to certain file paths, using up to 15 globs, and an approval only counts when every changed file matches one of them. New commits dismiss Copilot’s approval¹⁸.

I couldn’t find any documented way for Copilot code review to call an external webhook, emit a risk grade, or expose the approval assessment as an API field. It’s free text in a comment¹⁴. The review should show up as an ordinary pull_request_review event from copilot-pull-request-reviewer[bot], but that’s my inference from how GitHub reports other reviews, so check it against a live payload before you build on it.

GitHub’s documentation lists the limits itself. It says Copilot “is not guaranteed to spot all problems or issues in a pull request,” that its reviews “should be supplemented with careful human code review,”¹⁵ and that instructions are followed non-deterministically. Long instruction files may be partly ignored, and links inside them aren’t followed. Community threads describe Copilot commenting on one pull request and saying nothing about a near-identical one, which is why users have asked GitHub for a “deterministic review signal” on sensitive files²⁰.

Copilot Code Review on Azure Repos

GitHub Copilot code review for Azure Repos reached public preview for all Azure DevOps customers in Sprint 279 in September 2026²⁴. It doesn’t need a GitHub Copilot license. Each review is billed in GitHub AI credits through the linked Azure subscription²⁸. Admins enable it at the organization, project and repository level, turn on automatic reviews through a branch policy, and write custom instructions in organization or project settings or in instruction files in the repository²⁵.

Azure Repos has one real advantage over GitHub here. It reads repository and path-scoped instruction files from the target branch only, and Microsoft’s documentation states that “changes to instruction files in the pull request don’t affect its review.”²⁶ Audit-log events also cover enablement changes, instruction edits, default effort changes and new automatic-review branch policies²⁷.

The constraints are hard ones for an auto-approval design:

• Copilot “always leaves a Comment review. It never approves the pull request or requests changes, so its review doesn’t satisfy required-reviewer policies and doesn’t block merging.”²⁵
• It doesn’t re-review after new commits unless someone asks, and it doesn’t read replies to its comments.
• It only reviews active pull requests with no merge conflicts, in repositories of 10 GB or less, with 100 or fewer changed files.
• Concurrency is capped at 5 reviews per organization, 2 per user and 1 per pull request²⁵. In an organization whose pull request volume has grown quickly, automatic reviews will queue on busy days.
• Costs show up in Azure Cost Management about 48 hours after a review, and budgets send notifications without stopping reviews²⁸.
• During the preview, Microsoft confirmed an issue where reviews sat idle for about 60 minutes and were then canceled²⁷.

I also couldn’t find a documented service-hook event or pull request status for a finished Copilot review on Azure Repos. The practical trigger is the generic “Pull request commented on” and “Pull request updated” service hooks, plus polling³². Two documentation conflicts are worth checking in your own tenant. The Sprint 279 notes say Managed DevOps Pools are supported, while the current Learn page says they aren’t^24,25. All of Microsoft’s sources agree that self-hosted agent pools aren’t supported. The effort levels are called Lite and Balanced in a September 30 blog post but Low, Medium and High in Learn screenshots²⁷.

What Early Adopters Learned

Rewind’s first design made GitHub Copilot a required cross-check on every auto-approval. It didn’t last. Copilot kept “soft-blocking good auto-approvals on ‘I couldn’t review this PR’ boilerplate,” and Rewind moved it to advisory³⁶. That’s one of several lessons from the handful of companies that have published how they let AI approve pull requests. Their results are self-reported and cover short periods, but the controls they chose line up closely.

A few design constraints in these write-ups are easy to miss if you only look at the time savings. The first is Rewind’s experience above: plan for Copilot’s verdict text to be inconsistent, and give the gate a defined path for a review that’s missing or unusable.

Risk depends on what changed more than on how much. Rewind’s example is a 12-line migration that locks a 50-million-row table, which is high risk, next to a 3,000-line regenerated client, which isn’t³⁶. Path and domain rules do more of the work than line counts, although Ona and Intercom still cap size.

Ona and Intercom both keep a person accountable for the merge. Of all the controls in the table, that one carries over most easily to a regulated environment.

The headline numbers also carry selection bias. Intercom’s revert comparison is between AI-authored and human-authored code in general, and auto-approval only applies to changes that were already judged low risk. Independent commentary points out that selection explains part of the gap³⁹.

Other reports point the same way. Customer.io says its AI now approves more than 60% of pull requests, with zero production incidents after 500 AI-approved pull requests and median merge time down from 3.5 hours to 33 minutes³⁸. Greptile’s auto-approve feature, in beta since June 2026, requires a 5/5 confidence score plus a low risk classification, and always excludes changes that touch authentication, secrets or billing code.

How Much Review Can You Actually Hand Off?

The pitch for this approach often assumes that nearly all pull requests are low risk, sometimes as high as 95%. Some repositories may get close to that, especially ones that are mostly documentation, tests and dependency updates. The programs that have published numbers land well below that, though: about 19% at Intercom, about 40% at Rewind, and a little over 60% at Customer.io^34,36,38. I couldn’t find any published source supporting a figure near 95%.

A share in that range is still worth having. As an illustration, take a team that reviews 1,000 pull requests a month at an average of 30 minutes of reviewer time each. Auto-approving 40% of them frees about 200 hours a month, which is more than one full-time engineer. At 95%, it would free about 475 hours.

Two things pull the real number down. First, the low-risk pull requests are usually the quick ones to review, so they account for a smaller share of reviewer time than of pull request count. Handing off 40% of pull requests frees less than 40% of review hours. Second, repositories in SOX or PCI scope are usually excluded at the start, which shrinks the pool further. I’d plan the business case around 20% to 40% in the first year. Customer.io shows more is possible, but anything above that range is upside that shadow-mode data has to earn.

Security Risks of AI Pull Request Approval

As long as Copilot only leaves comments, a bad review costs you some time. Once its output can approve a change, it’s part of your security controls, and it needs the same threat modeling you’d give any other control.

Prompt injection

Prompt injection against AI reviewers has already been demonstrated in testing. Cloudflare tested seven models across 18,400 API calls and found that when malicious code carried a few misleading comments (under 1% of the file), average detection fell from 67.3% to 53.3%^42,46. Heavier commenting actually raised detection, so the effective attack is a light touch. The GitInject study (arXiv 2606.09935, June 2026) reports that a fake “internal audit notice” in a pull request description, telling the reviewer to approve, “succeeds against codex-pr-review and gemini-assistant,” while claude-pr-review resisted it in the authors’ tests. The authors caution that this resistance is model-specific, and in another test Claude did follow an instruction to approve that was planted in a CLAUDE.md file⁴⁷. In April and May 2026, the Cloud Security Alliance documented injections through a pull request title, an issue title with follow-up comments, and a hidden HTML comment that hijacked Anthropic’s Claude Code security review action, the Gemini CLI action and GitHub Copilot’s agent in CI^43,44.

Everything Copilot reads is under the control of whoever opens the pull request: the diff, the comments, the description, and on GitHub the head-branch instruction files.

Excessive agency

Giving the reviewer permission to approve creates a direct path from prompt injection to an unauthorized approval. I’d keep the component that reads untrusted content (Copilot) separate from the one that evaluates risk and holds permission to vote (deterministic logic in the Function). At worst, an injected instruction then changes what a comment says. It’s the same principle behind an agentic harness: the harness, not the model, holds the permissions.

Time of check to time of use

Copilot reviews a specific commit, and the author can push again afterward. GitHub dismisses Copilot’s approval on new commits. On Azure DevOps, protection depends on whether the minimum-reviewer policy resets votes on push. Without that setting, a bot approval for an earlier commit can carry new code that nobody reviewed.

Webhook spoofing and replay

Azure DevOps webhooks support basic authentication, and Microsoft requires HTTPS when you use it³². Even so, the safest design treats an incoming webhook as nothing more than a signal to go look. The Function should read the pull request ID from the payload, ignore everything else, and fetch the authoritative state itself.

A Reference Design for Risk-Gated Approval

The design that holds up on both platforms puts the decision in code you control. Copilot reviews the pull request and contributes findings. An Azure Function gathers deterministic signals, reads Copilot’s review as one input that can only raise the risk grade, and acts only on the exact commit it assessed. People still complete every merge and review every sensitive path. (For the broader pattern, see our Agentic Harness Architecture in 2026 white paper.)

Azure DevOps

1. Subscribe the Function to the “Pull request created,” “Pull request updated” and “Pull request commented on” service hooks over HTTPS, with basic-auth credentials stored in Key Vault³². Add a timer that sweeps every 5 to 10 minutes for missed events and reviews stuck in the queue. Use nothing from the payload except the pull request ID.
2. Run the Function as a managed identity or Entra service principal added to the Azure DevOps organization, with only the “Contribute to pull requests” permission on the repositories in scope. Never use a developer’s personal access token. Give the identity a name that’s easy to spot in an audit sample, such as “AI Risk Gate,” and make sure it never creates pull requests, so the “allow requestors to approve their own changes” setting never applies to it.
3. Fetch the authoritative state through the Git REST API. Confirm that the pull request is active and targets an in-scope branch, and record the last merge source commit and iteration ID, the reviewers and their votes, and the policy evaluations, including build validation and GitHub Advanced Security for Azure DevOps checks. Pull the iteration’s file list and diff stats, and find the Copilot review thread for that specific iteration.
4. Compute the grade in the Function. The deterministic signals do most of the work: the paths touched (auth, crypto, infrastructure as code, pipeline YAML, migrations, dependency manifests and lock files, secrets configuration, Copilot instruction files), diff size and file count, new dependencies, whether tests changed along with the code, SAST, SCA and secret-scanning results, and whether build validation passed. Treat Copilot’s 100-file limit as an automatic escalation. Copilot’s own signal, such as an unresolved comment above a severity threshold or a RISK: LOW|MEDIUM|HIGH line you ask for in its instructions, can raise the grade but never lower it below what the rules set. If Copilot’s review is missing, canceled, partial or for an older commit, fail closed.
5. Post a pull request status, for example with the genre ai-risk and the name assessment, carrying the grade, the rules that fired and a link to the evidence record. Make it a required status policy, with the authorized identity set to the Function’s principal so nobody else can post a passing status, and set it to reset when the source branch changes^29,33.
6. For low-risk pull requests only, fetch the pull request again immediately before voting and confirm the source commit still matches the one assessed. Then cast an approve vote (a vote of 10) through the pull request reviewers REST API³¹. The minimum-reviewer policy must reset all approval votes on new pushes, or something stricter³⁰.
7. Keep a human-only floor with Azure DevOps’s automatically included reviewers, using path filters for the sensitive areas in step 4. The bot’s vote counts toward the minimum number of reviewers, but it can’t satisfy a named, required human group, so the floor holds even if the grade is wrong or manipulated³⁰.
8. Escalate medium- and high-risk pull requests to a Teams channel with the link, the grade and the reasons, through whichever inbound mechanism your tenant supports today (Workflows, Power Automate or Graph). Optionally add the owning team as a reviewer and set a review SLA.
9. Leave completion to a person. The Function shouldn’t set auto-complete. The author or another person clicking Complete is the accountable shipping event, which is how Ona and Intercom anchor their programs^34,35.
10. Write an immutable record of every decision to append-only storage and forward it to the SIEM. Each record should hold the pull request, iteration and commit IDs, the rules that fired, the Copilot thread IDs, the grade and decision, and the Function and policy versions. Keep the policy rules and instruction files in a repository where changes need approval from security or enterprise architecture.

GitHub

On GitHub there are two reasonable options.

The simpler one uses Copilot’s native approvals. Turn approvals on at the organization or repository level, restrict them to a narrow path allowlist, and rely on GitHub dismissing them on new commits. Keep “Require review from Code Owners” on sensitive paths. A GitHub App can’t be a code owner, and GitHub’s guidance is not to assume a Copilot approval satisfies a code-owner requirement^18,21. The Function then handles only deterministic scoring, the required status check and Teams notifications.

The other option mirrors the Azure DevOps design with a GitHub App as the approver. The Function listens for pull_request and pull_request_review events, fetches the pull request again, checks head.sha against the commit Copilot reviewed, and posts a required check run. It submits an approving review only for low-risk changes. GitHub App approvals do count toward required approvals. An October 2026 issue in the MergeWatch project documents this and shows how a bot that re-approves can defeat “dismiss stale approvals,” so the App must never re-approve without a fresh assessment²². Rulesets should require the ai-risk/assessment check with the App as its only allowed source, code-owner review on sensitive paths (including .github/copilot-instructions.md, .github/instructions/**, AGENTS.md and workflow files), approval of the most recent push, and dismissal of stale reviews. Add a merge queue if you want checks run again against the merged result.

Either way, because Copilot on GitHub loads instructions from the head branch, any pull request that touches instruction, agent or skill files should be graded high risk automatically and need code-owner review.

A status check, a bot approval or both

A required “AI risk assessment passed” status check is a cleaner and more auditable gate than a bot vote. Only the Function’s identity can post it, it resets on push, and an auditor can see it’s a control and not a reviewer. On its own, though, it doesn’t satisfy a minimum-reviewers policy. In practice I’d use both. The bot only votes when the status check is green, and that vote fills the reviewer count. Path-filtered human reviewers stay in place regardless.

If your auditors object to non-human votes, the fallback is to set the minimum reviewer count to zero for a clearly defined low-risk class, while keeping the required status check and the path-filtered human reviewers. That’s a policy decision you should document, and I wouldn’t use it to get around a control.

Getting SOC 2 and Compliance Sign-Off

The frameworks most organizations answer to, including SOC 2, don’t require a human approver in so many words. Auditors still expect an independent review and a person who’s accountable for it, and they’ll want evidence of both, so the control has to be designed with that in mind from the start.

Practitioners don’t agree on whether AI-only approval passes an audit. In an October 8, 2026 article, Axipro’s Pedro Dias says that “no major certification body or CPA firm currently accepts AI-only approval for production changes.”⁵² Intercom, on the other hand, reports working with Schellman to confirm that its automated review evidence meets SOC 2, HIPAA, ISO 27001 and ISO 42001 requirements³⁴. Workstreet’s position sits between the two: AI can perform the review, but a human should own approval “unless the company has formally defined and tested an automated approval process.”⁴⁹ In practice the answer depends on your auditor and on how the control is written, which is why I’d bring the external auditor in before go-live.

For SOX, expect auditors to ask for a decision-authority matrix that shows what the AI may decide on its own and what needs human review. Expect a separate question about who can change the AI’s prompts and rules, and how that access is reviewed⁵¹. For repositories in ICFR or PCI scope, the most defensible starting point is that AI speeds up and grades the review while a qualified person still approves.

The sign-off package

These are the documents I’d prepare for information security, enterprise architecture and the auditor.

• A control narrative that defines independent review as a property of the pipeline. The reviewer’s configuration is version-controlled and can’t be changed by the pull request’s author, which Azure Repos provides natively by reading instructions from the target branch, and which you have to enforce yourself on GitHub. The merge is mechanically gated, and a person completes it.
• A risk-tier policy with deterministic eligibility criteria and an explicit list of changes that are never auto-approved. Ona’s six criteria make a good starting template³⁵. Engineers can’t classify their own changes.
• A risk assessment in the style Rewind used³⁶, listing the failure modes (a false approval, a malicious pull request approved through injection, theft of the Function’s credentials, drift in the model or instructions, tampering with the policy, and a Copilot outage or partial review) with their mitigations and a signed acceptance of the residual risk by a named risk owner.
• Change control on the gate itself. Policy files, instruction files, the Function’s code, and the model and effort settings change only through pull requests that security approves, and swapping the model counts as a material change. Azure DevOps audit-log events for Copilot settings go to the SIEM.
• Evidence and sampling. Every auto-approval is labeled and queryable, and a risk-weighted sample is reviewed again by a person, as Anthropic does³⁷. I’d start by re-reviewing 10% to 20% of auto-approved pull requests, and file the results as evidence.
• Metrics with promotion and rollback gates: agreement with human reviewers (Rewind used a 90% gate³⁶), escaped defects, reverts and incidents linked to auto-approved pull requests (with a target of zero), override usage, queue and pickup time, and Copilot’s failure rate.
• A kill switch. A configuration flag that drops the Function to grading and notifying only, plus a documented way to remove the service principal’s permission to vote. Write down who can use it and when they must.

For framing, map the program to the NIST AI Risk Management Framework’s four functions (Govern, Map, Measure and Manage) and to OWASP’s Top 10 for LLM applications, which covers prompt injection (LLM01) and excessive agency (LLM03 in the 2026 edition, LLM06 in 2025). Cite the current versions of both directly in the sign-off documents.

Alternatives That Often Pay Off Sooner

Auto-approval gets the attention, but it’s not the only lever, and it’s not the cheapest. None of the changes below is a silver bullet either, but most of them chip away at the same bottleneck and make an auto-approval gate safer if you build one later.

Small batches are the first. DORA’s AI Capabilities Model names working in small batches as one of its key capabilities¹¹, and Intercom’s and Ona’s agents refuse or escalate large pull requests, which pushed their engineers toward smaller ones. Not everyone agrees. Rootly dropped its small-pull-request rule and relies on risk labels, blast radius, revert plans and feature flags instead, moving its safety boundary from the merge to the rollout⁴¹. Which one fits depends a lot on how mature your feature flags and rollback process are, so I’d pick one on purpose.

Moving checks earlier helps whether or not AI ever approves anything. Make SAST, secret scanning, dependency review (GitHub Advanced Security or its Azure DevOps equivalent), linting and tests required before any person or AI looks at the pull request. A deterministic tool catches its class of bug every time, which Copilot doesn’t promise to do.

CODEOWNERS and path-filtered required reviewers send sensitive changes to the right experts. They’re the same mechanism that forms the human floor in the reference design, so setting them up now isn’t wasted work.

LinearB’s data says the wait for a reviewer costs more than the reading, so fixing pickup can pay off quickly. Review SLAs, reviewer rotation and load balancing all help, and so does turning off organization-wide auto-assignment of reviewers, which Ona did³⁵. Letting Copilot take the first pass means a person starts from a pull request that has already been triaged.

For the lowest-risk class, a Ship/Show/Ask model or review after merge can work, backed by feature flags, fast rollback and production monitoring. Intercom notes that most of its largest outages weren’t caused by product code changes at all, so pull request review was never going to catch them³⁴.

For high-risk work, pairing or mob programming can stand in for asynchronous review, because the review happens while the code is written.

A Phased Rollout Plan

This is how I’d roll it out on Azure DevOps. I’d only move to the next phase once the current one meets the agreement and incident thresholds you set up front.

1. Weeks 0 to 2, foundations. Turn on Copilot code review for one or two repositories, which is what Microsoft recommends²⁵, with organization-level instructions that cover your security standards. Set the minimum-reviewer policy to reset votes on push, add path-filtered required reviewers for sensitive areas, and require build and security checks. Draft the risk-tier policy and risk assessment with security, enterprise architecture and GRC as co-authors, and brief the external auditor.
2. Weeks 2 to 6, shadow mode. The Function grades every pull request and posts an optional status and Teams messages, but never votes. People review everything and record whether they agree with the grade. Measure Copilot’s failure and queue rates against the cap of five concurrent reviews per organization, and track cost knowing it shows up about 48 hours late.
3. Weeks 6 to 12, limited enablement. In repositories outside SOX and PCI scope only, turn on votes for the strictest low-risk class, such as documentation, tests and dependency patch updates with a clean SCA scan. Make the status check required, re-review a sample of 10% to 20% of auto-approvals, and continue only with zero linked incidents and at least 90% agreement.
4. The second quarter and beyond, expanding by evidence. Widen the eligible paths one repository at a time, run a control review every quarter, and revisit compliance-scoped repositories only with your auditor’s explicit agreement.

On GitHub, pilot Copilot’s native approvals with path allowlists before building a custom GitHub App, and put the instruction files under CODEOWNERS on the first day.

Where I’d Start

AI coding tools made writing code a lot cheaper, and the review queue hasn’t caught up. Asking people to review faster doesn’t scale, and reviewing less without admitting it leaves you with a control that exists only on paper. Risk-based code review with automated approval is a reasonable way out, and the companies that have published results show it can be done safely.

They built it differently, but the published programs share the same controls: deterministic eligibility rules, an AI reviewer that contributes findings without making the final call, decisions tied to the exact commit assessed, escalation for sensitive paths, and a person who still ships the change. Copilot’s current limits on both platforms push you toward that design anyway, since it can’t return a structured grade and, on Azure Repos, can’t approve.

I’d also set expectations carefully. The published programs auto-approve somewhere between a fifth and three-fifths of their pull requests, which is a big gain but well short of the 95% that sometimes gets pitched. If I were starting this tomorrow, I’d run it in shadow mode first, let the agreement data tell me how far to go, and bring the auditor in before the bot casts its first vote.

At Keyhole, we help teams put guardrails like these around AI-assisted delivery. I’m curious what others are seeing, especially what share of pull requests your teams have been comfortable handing off, and what your auditors said when you asked.

How We Researched This

We reviewed GitHub and Microsoft documentation and changelogs, published case studies, industry benchmark reports, security research and compliance guidance, all current as of mid-October 2026. A few limits apply to what’s here.

• Most of the Copilot features cited are in public preview, including code review for Azure Repos and Copilot approvals on GitHub, and they changed several times between June and October 2026. Behavior, limits and names may be different by the time you implement.
• The mapping of a finished Copilot review to webhook events on both platforms is our inference and isn’t documented. Validate it against live payloads before relying on it.
• The case-study results are self-reported by companies, some of which sell products in this space. They cover short periods and carry selection effects.
• The industry figures come from analytics vendors (Faros AI and LinearB) with products in this space. They point the same way but aren’t peer-reviewed.
• Whether auditors accept AI-only approval is unsettled. Treat any single firm’s position, in either direction, as a data point for the conversation with your own auditor.
• The reviewer-hours example in “How Much Review Can You Actually Hand Off?” is an illustration, not measured data.

References

Industry data and research

1. DORA Report 2025 Key Takeaways: AI Impact on Dev Metrics, Faros AI
2. Bain Technology Report 2025: Why AI Gains Are Stalling, Faros AI
3. The AI Productivity Paradox: Why AI Adoption Hasn’t Made Engineering Faster, Augment Code
4. Engineering benchmarks 2026: data from 8.1M pull requests, LinearB
5. Why AI-generated pull requests wait 4.6 times longer for review, PRLens
6. DORA’s 2025 research on the impact of AI, DX
7. State of DevOps 2025: Review of the DORA Report on AI Assisted Software Development, Splunk
8. Code Review Is the New Bottleneck in AI-Assisted Development, QA.tech
9. The AI Productivity Paradox Report 2025, Faros AI
10. These Aren’t the Reviews You’re Looking For, Duma et al., arXiv, May 2026
11. Introducing DORA’s inaugural AI Capabilities Model, Google Cloud

GitHub documentation

12. Using GitHub Copilot code review on GitHub, GitHub Docs
13. Configuring code review by GitHub Copilot, GitHub Docs
14. GitHub Copilot code review, GitHub Docs
15. Responsible use of Copilot code review, GitHub Docs
16. Using custom instructions to unlock the power of Copilot code review, GitHub Docs
17. Copilot code review: Customization and configurability improvements, GitHub Changelog, July 17, 2026
18. Copilot code review can now approve pull requests, GitHub Changelog, September 1, 2026
19. Copilot code review: API support and new default effort level, GitHub Changelog, October 2, 2026
20. Copilot Code Review: deterministic review signal for CODEOWNERS and workflow changes, GitHub Community
21. GitHub Copilot PR Approvals: Keep Human Review Required, General Analysis
22. MergeWatch APPROVE reviews count toward required approvals, issue #706, MergeWatch on GitHub

Microsoft and Azure DevOps documentation

23. GitHub Copilot code review for Azure Repos is now in technical preview, GitHub Changelog, June 2, 2026
24. Sprint 279 release notes, Microsoft Learn
25. Get started with Copilot code review for pull requests, Microsoft Learn
26. Configure Copilot code review instructions, Microsoft Learn
27. Updates to Copilot Code Reviews for Azure Repos, Azure DevOps Blog
28. Copilot Code Review Reaches Azure Repos, Billed Per Review with Reporting Two Days behind, InfoQ
29. Configure a branch policy for an external service, Microsoft Learn
30. Set and manage branch policies, Microsoft Learn
31. Pull Request Reviewers: Create Pull Request Reviewer, Azure DevOps REST API
32. Webhooks with Azure DevOps, Microsoft Learn
33. Create a pull request status server with Azure Functions, Microsoft Learn

Case studies

34. AI is approving our pull requests: Here’s how we made it safe, Intercom
35. How auto-approving low-risk PRs with AI cut our lead time by 74%, Ona
36. Review is the bottleneck now: How we let AI approve pull requests (safely), Rewind
37. How Anthropic secures its AI-native software development lifecycle, Anthropic
38. How we taught AI to approve pull requests, Customer.io
39. Can AI Agents Safely Approve Pull Requests? Guardrails for Autonomous Code Review, Augment Code
40. Coding Agents Drive 93 Percent of Intercom Pull Requests, The Innovation Attorney
41. Why we got rid of our small-PR rule, Rootly

Security research

42. Cloudflare warns of AI code review prompt injection, SecurityBrief
43. Comment and Control: GitHub prompt injection research note, Cloud Security Alliance, April 2026
44. Prompt Injection in AI-Powered GitHub Actions, Cloud Security Alliance, May 2026
45. Treat Copilot Code-Review Instructions as Untrusted Policy Input, DEV Community
46. Adversarial deception: a study of indirect prompt code injection, Cloudflare Cloudforce One
47. GitInject (arXiv 2606.09935), Isbarov et al., June 2026

Compliance and governance

48. AI Code Review and SOC 2 Type 2: Can an Agent Approve?, YSecurity
49. Can AI Agents Satisfy SOC 2 Code Review Requirements?, Workstreet
50. PCI DSS 4.0 requirement 6 and code review evidence, Vulkro
51. What Your SOX Auditor Will Ask About Your AI Automation (and How to Answer It), Kognitos
52. AI-generated code and SOC 2 / ISO 27001 change management, Axipro, October 8, 2026