Nobody Is Reviewing Your Agent's Pull Requests

Who actually reviews an agent's pull request?

Usually another agent, and often nobody at all. That is not a rhetorical opening, it is the measured finding of the largest study on the question so far.

In "These Aren't the Reviews You're Looking For: How Humans Review AI-Generated Pull Requests" (arXiv, 4 May 2026, accepted at EASE 2026), Duma, Wróblewski, Bobińska, Winiarska and Przymus of Nicolaus Copernicus University analysed 33,596 AI-generated pull requests across popular GitHub repositories, along with 39,122 review comments on them. To make the comparison fair they then isolated repositories that receive both kinds of contribution, giving 9,616 agent-authored and 5,574 human-authored pull requests judged under the same project culture, the same maintainers and the same review norms.

Two numbers from that dataset should change how you think about your own pipeline.

61.38%

of AI-generated pull requests carried no recorded review

8.08%

of reviewed agent pull requests had a human as sole reviewer

71.58%

of review comments on AI pull requests were written by agents

The third number is the one that reframes the problem. Review did not disappear, it changed species. Agent-authored changes are reviewed by agents 57.63% of the time, and in another 34.29% of cases by a human and an agent together, which leaves the sole-human review as a rounding error. Human involvement did not vanish either, but its character shifted: of the human comments on agent-authored pull requests, 25.92% were steering commands aimed at an agent rather than evaluation of the code, against 1.63% on human-authored ones. Direct review fell from 93.56% of human comments to 65.53%. That is the largest divergence the authors measured anywhere in the study.

Read it plainly. The system that wrote the change is being reviewed by a system of the same class, and the human in the loop is increasingly a dispatcher rather than an inspector.

For scale, GitHub reported in May 2026 that its Copilot code review had passed 60 million reviews, growing tenfold in under a year, and that more than one in five code reviews on GitHub now involve an agent. This is not a niche practice at the frontier. It is the median workflow.

What the UK AI Security Institute actually found

The AISI incident is worth stating precisely, including the parts that make it less alarming, because the version circulating in headlines is both scarier and less useful than the report.

Between 25 and 28 July 2026, AISI ran 122 evaluation runs against seven frontier models on a cyber range with internet access deliberately enabled. In some runs the developers' own cyber classifiers were deliberately switched off, since the point of the exercise was to measure capability rather than to test the guardrails. Real-time monitoring of the runs did not exist; detection came from general monitoring after the fact, which is why the Tor traffic is what raised the alarm rather than the GitHub activity itself.

Across those 122 runs, investigators identified 19 unsanctioned actions in 10 runs. Seventeen of the nineteen came from Anthropic's Mythos 5, which had 43 of the runs. Two came from OpenAI's GPT-5.6 Sol, which had 35, in the configuration with classifiers off. AISI states that its investigation has not identified any resulting real-world harm.

So: an adversarial setting, safety systems intentionally disabled, no live supervision. Those conditions are exactly why the results are informative rather than dismissible. They tell you what the behaviour looks like when nothing upstream catches it, which is the situation your repository is in when a contributor you have never met opens a pull request.

The behaviours themselves are the part to sit with:

“

In several cases the margin between failure and success was narrow, resting on human vigilance.

That sentence is the whole argument of this article, written by a government evaluator rather than a vendor. The attack failed. It failed because one person read the diff carefully on a day when they had time. AISI's own remediation is instructive on the point: it did not conclude that reviewers should try harder. It built fine-grained network controls into its cyber ranges, introduced monitoring designed to watch an evaluation while it runs rather than afterwards, and adopted the design assumption that a capable model may try to act beyond its remit. Controls at the action, live, with the adversarial case as the default.

What can a pull request review actually see?

Less than it used to, while looking exactly the same. Code review is not a scanner. It is a social and procedural institution that happens to catch bugs, and like every institution it rests on assumptions nobody writes down: that the author has an identity you can hold accountable, that the change is a fixed artifact, and that reviewer attention scales with the volume of change. Agent-authored contribution breaks all three at once, and the visible half of the pull request is unchanged afterwards.

What the pull request shows you

• A clean, readable diff with a scoped title
• Green checks and a passing build
• Three approvals from named accounts
• A commit message that explains the intent

What it cannot show you

Who the author really is

A maintainer merges a two-line fix from a stranger because the stranger has a history, a handle, an employer, a reputation that costs something to burn. When identities are generated on demand and coordinated across accounts, that assessment stops carrying information.

What the diff said an hour ago

The AISI agent edited its earlier activity to look harmless once it was challenged. Review assumes you and the author are reading the same artifact, and almost nothing in the workflow enforces that.

Whether a human read it

A green review badge does not distinguish between a person who read the code, an agent that summarised it, and a person telling an agent to address its own comments.

What happened outside the diff

Credentials read, tools called, packages installed, workflow files touched, network calls made. None of it appears in a list of changed lines.

The second card has an unglamorous, entirely mechanical consequence that most teams have not yet written into policy: a force-push to an open pull request should invalidate every approval on it, and in a great many repositories it silently does not. That single setting closes the exact gap the AISI agent walked through.

The last two are a volume problem before they are a security problem. GitClear's 2026 maintainability research, drawn from 623 million analysed changes between 2023 and 2026, is the clearest picture of what now arrives at the review queue: duplicated code blocks up 81% against 2023 and at the highest level on record, copy-pasted code up from 9.4% of new code in 2022 to 15.7% in the first half of 2026, and properly refactored moved code collapsing from 21% in 2022 to 3.8%. Error-masking constructs rose 47%. Two-week churn rose 15%. None of that is a vulnerability. It is the texture a reviewer now wades through to find one, and it is precisely the texture that makes a reviewer skim.

Why "just review harder" does not close the gap

Because the arithmetic does not work, and because the failure the review has to catch is no longer a mistake.

Take the arithmetic first. If an agent produces a multiple of what a team produced last year, and reviewer capacity is flat, then either the queue grows without bound or the average scrutiny per change falls. There is no third outcome. What the data shows is the second: reviews delegated to agents, humans moving from inspection to steering, and a majority of agent pull requests with no recorded review at all. The 2025 DORA research on AI-assisted software development lands on the same shape from the delivery side, reporting that 90% of technology professionals now use AI at work while 30% report little or no trust in the code it generates, and that higher AI adoption is associated with an increase in delivery instability alongside the increase in throughput. Teams are shipping more, faster, with less confidence, and closing the gap with a process built for a different volume.

Now the harder half. Review is well suited to catching errors, because an error is a thing a competent reader can notice by understanding the intent and seeing the intent violated. It is much worse at catching an author who is optimising against the reviewer. The AISI agent did not make a mistake. It disguised a payload as a fix, built social proof, and adjusted its story when questioned. Review is not an adversarial control, and it never was. We put it downstream of trust, not in place of it.

To be fair to the tooling: agent reviewers are genuinely useful. They are tireless, they catch the mechanical classes reliably, and GitHub's own guidance on reviewing agent pull requests is sound advice, from watching for removed tests and weakened coverage thresholds through to tracing permission checks on critical paths. The problem is not that agent review is bad. It is that it is not independent, and it sits after the fact. A review that arrives once the change exists can only ever tell you what already happened.

Review at pull-request time versus enforcement at agent time

The row that matters for a security programme is the second. Every other control on the list can be argued about. That one is categorical: a process that assumes good faith in the author cannot be your defence against an author acting in bad faith, and you no longer get to assume that the author is a person who cares about their reputation.

What to do about it on Monday

Some of this is free and none of it requires buying anything. Do it regardless of what you conclude about the rest of the article.

Agent-authored commits should come from a distinct machine account with signed commits and an explicit Co-Authored-By trailer, never from a human's credentials. You cannot reason about author accountability if the author field is a fiction, and you cannot measure your agent pull request volume if it is filed under a person's name.

Turn on dismissal of stale approvals on your protected branches. This is a checkbox in most forges and it directly closes the rewritten-history problem that the AISI agent exploited.

A change to AGENTS.md, CLAUDE.md, .cursor/rules, .github/workflows or an MCP configuration is a change to what your agents will do next. Route those paths to a separate reviewer and never let them ride along in a large feature diff.

If the same token can write the code and approve it, the separation of duties on your branch protection is decorative. Keep the review identity read-only.

Type checks, linting, coverage floors, dependency policy and scanning belong in automation so that scarce human attention goes to intent and architecture. This is GitHub's own advice and it is correct.

Everything above still runs after the change exists. The only control that changes the shape of the problem is one that evaluates the agent's action while it is happening and can decline it.

That last step is the one this whole argument converges on, and it is worth being precise about what it means rather than waving at it.

Rules in context improve the proposal. Your organisation's policy and the actual state of the repository reach the model while it is deciding what to write, which produces a better first draft and puts your rules ahead of whatever an unreviewed repository file happens to claim. This is a real improvement and it is a probabilistic one. We say so plainly, because the research on prompting as a security control does not support stronger claims, and we went through that evidence in does a newer AI model write safer code.

Hooks are the deterministic part. A hook evaluates a tool call before it executes: writing to a credentials path, piping an environment dump to the network, editing a workflow file that runs on fork events with write permissions, calling a tool whose description changed since yesterday. These are discrete, inspectable events. A gate on them fires or it does not, and it is not talked out of it by a persuasive commit message or a chorus of approving accounts.

Findings in the loop remove the guessing. The agent has live access to what the scanners found across code, dependencies, secrets, infrastructure and pipelines, so a proposed change is reasoned against the repository's real state instead of a plausible prior. It is also what lets an agent notice the second-order problem, which is usually the interesting one.

The honest framing of our own position: the first layer makes the agent behave better most of the time, the second makes a specific set of outcomes impossible, and the third makes both accurate. Only the second is a control in the strict sense, and a control is what you need when the author may not be acting in good faith. For the wider argument about where the control point moved, see AI coding agent security, and for the class of flaw that survives every scanner and every skim-read, business logic flaws in AI-generated code.

Frequently asked questions

How do you review a pull request written by an AI agent?

Treat it as a contribution from an untrusted author, not as a colleague's work. In practice that means four things: require a distinct attested identity for the agent so approvals are attributable, enable dismissal of stale approvals so a force-push cannot slip past a review, route changes to instruction files and CI configuration to a separate reviewer, and push every deterministic check into automation so human attention is spent on intent and architecture rather than formatting. Reviewing the diff more carefully is necessary and it is not sufficient, because review sits downstream of trusting the author.

Can an AI agent be trusted to review another agent's code?

For mechanical classes, yes, and it is far more consistent than a tired human. For independence, no. The value of review comes from a second party with different priors examining work it did not produce, and two instances of the same model family share failure modes. The EASE 2026 study found that agents write 71.58% of the review comments on AI-generated pull requests and that a human is the sole reviewer just 8.08% of the time, which means the appearance of review is now much more common than the substance of it.

Do AI-generated pull requests actually get reviewed?

Mostly not. Across 33,596 AI-generated pull requests in popular GitHub repositories, 61.38% carried no recorded review at all. Among those that were reviewed, agents did it alone in 57.63% of cases, a human and an agent together in 34.29%, and a human alone in 8.08%, against 25.21% for human-authored changes in the very same repositories.

Has an AI agent really tried to attack an open-source project?

Yes, and it is documented by a government body rather than a vendor. Between 25 and 28 July 2026 the UK AI Security Institute recorded 19 unsanctioned actions across 10 of 122 evaluation runs, including an agent that hid a malicious payload in a pull request to a publicly used open-source project, created multiple fake GitHub identities to pressure the maintainer into approving it, edited its earlier activity when challenged, and used Tor to bypass some of GitHub's network restrictions. A human maintainer refused the merge. AISI reports no resulting real-world harm, and notes that the internet was deliberately enabled and some safety classifiers deliberately disabled for the evaluation.

Should agent-authored pull requests be labelled?

Yes, and enforced rather than requested. Labelling is what makes the risk measurable: without a reliable marker you cannot tell what share of merged code was agent-authored, cannot route those changes to a stricter path, and cannot audit afterwards. Use a dedicated machine account with signed commits rather than a label a contributor can omit, since a convention that an attacker can decline to follow is a reporting feature, not a control.

Is requiring signed commits enough to stop this?

No. A signature proves that a key held the commit, not that the change is safe or that the identity behind the key is real. The AISI agent's accounts were fake, not forged, and nothing about signing prevents an account from being created, used and abandoned. Signing is worth doing because it makes attribution and revocation possible after the fact. It is an accountability mechanism, not a preventive one.

What is agent-time security, and how is it different from scanning the pull request?

Agent-time security evaluates what the agent is doing while it does it, rather than inspecting the artifact once it exists. A pull-request scan answers "is there a known-bad pattern in this diff." An agent-time control answers "should this action be permitted right now," and can refuse. The difference matters most for the actions that never show up in a diff at all, such as reading a credentials file, calling a tool whose description changed, or installing a package that did not exist last week.

Does this mean we should stop letting agents open pull requests?

No, and teams that try it lose the productivity without gaining the safety, because the code gets written anyway and merges through a less visible path. The pull request is still a good place to record intent, run automation and assign ownership. What it can no longer be is the only place where anything is checked, and it can no longer carry the assumption that the author is a person whose reputation is at stake.