AI PR Review Agent Policy: Agents Propose, Humans Merge

Suppose the coordinator opened nine pull requests last night and a second agent reviewed all nine before you woke up. Seven carry a green “LGTM” from the reviewer. The reviewer and the implementer share a bot account, a system prompt, and a shared-context folder, which makes the seven approvals the sound of one hand clapping. Nobody with a pulse has read the lockfile bump.

This is the policy piece for an AI PR review agent: what it may do, what it may never do, which paths always route to a named human, and how you know whether its comments are worth reading. The rule is short. Review agents propose. Humans, or a policy humans signed, merge. Everything below is the plumbing that makes the rule hold when the agents outnumber the reviewers.

You will leave with a path-class matrix, a CODEOWNERS-style policy shape, three identity rules, and reviewer-quality numbers you can compute today.

Sep 10 and Aug 19: review subagents, PR subscriptions, and “you review less”

Cursor’s Projects beta (Sep 10, 2026) describes a coordinator that “plans the work, delegates it to agents that implement it, and brings the finished work back to you to check,” with agents sent “to implement and test different parts of it in parallel” (blog; changelog). The review passage: “Early on, you review each PR closely. As the fixes hold up, you review less, and the coordinator keeps working through the migration on its own.”

Screenshot: Cursor blog, “Introducing Projects” (Sep 10, 2026), captured Sep 13, 2026.

The subscription side arrived earlier. The Aug 19, 2026 changelog entry, “Cloud Agents and Cursor Harness Improvements,” says cloud agents automatically subscribe to PRs they create, fix CI, and address bot comments; the Sep 10 entry adds a coordinator you can tell to follow all your PRs. Together: agents that write PRs and answer reviews on one repository while the humans sleep. Neither cited changelog entry documents a permission model for those actions, so this policy does not infer one. The news stops here.

Screenshot: Cursor changelog, “Cursor Projects” (Sep 10, 2026), captured Sep 13, 2026.

Why an AI PR review agent needs a policy before it needs a prompt

A review bot that comments is a linter with opinions. One whose approval counts toward a merge rule is a privileged user, and agents are privileged users whether or not anyone wrote that down. The moment a review agent’s “approve” satisfies a required-reviewer count, the trust ramp Cursor describes has no floor.

The ramp itself is the thing to design for. “As the fixes hold up, you review less” describes a habit, and habit is how the approve-once pattern failed for MCP servers: a review true in June, never re-run, standing in for a control (approve-once is dead). The fix has the same shape here: turn the habit into a policy with a scope, an evidence requirement, and a way to narrow again.

The policy in one line, and the three things it forbids

At the top of the policy file:

A review agent may read, comment, suggest, and mark a pull request as blocked. It may not approve, merge, dismiss a human review, or change the rules that decide who may. Merges come from a human reviewer or from a signed policy that names the path classes it covers.

The three things it forbids are the three things vendors will offer you first. Approve, because a green check from a reviewer looks like progress. Merge, because “automerge when checks pass” is one toggle away. Dismiss, because an agent that can dismiss a stale human review can clear its own path.

Always-human paths: the list you write first

The matrix below is the policy’s heart: path classes against the three things that could press merge. The first column is all “never,” and that column is the self-approval loop, cut.

Illustrative, one team’s starting point. No path class lets a review agent merge or approve.

The always-human classes, and why each is on the list:

Path class	Examples	Why always human
Secret and credential paths	.env*, *.pem, secrets/	A wrong change is a leak, and rotation is a human call
Lockfiles and dependency manifests	package-lock.json, pnpm-lock.yaml, poetry.lock, Cargo.lock, go.sum	A bump is a supply-chain decision made at 3 a.m.
Infra modules	infra/, terraform/, *.tf, Helm charts	A production change dressed as a code review
CI and workflow config	.github/workflows/, pipeline files, the policy file itself	An agent that edits this edits its own leash
Auth and crypto code	services/auth/, session handling, token issuance	Failures are silent and expensive
Data migrations	db/migrations/	Irreversible on production data

Everything else is negotiable, and the negotiation is the signed policy two sections down. Docs, test-only changes, and small application code are the classes where “review less” can become a rule with a scope. The overnight merge gates sibling covers the gates themselves; this piece assumes they exist and decides who may act on their result.

A CODEOWNERS-style policy shape for AI PR review agents

GitHub already has a file that maps paths to required reviewers, and branch protection already knows how to require a code owner’s approval (docs.github.com). Use it as the enforcement half of the policy, and keep a second file, the policy, as the readable half. Only human teams appear in the first; no bot identity, ever.

/infra/                     @org/platform-oncall
/terraform/                 @org/platform-oncall
/.github/workflows/         @org/platform-oncall
/.github/agent-policy.yml   @org/platform-oncall @org/security-review
/services/auth/             @org/security-review
/secrets/                   @org/security-review
package-lock.json           @org/platform-oncall
pnpm-lock.yaml              @org/platform-oncall
/db/migrations/             @org/data-oncall

The policy file, .github/agent-policy.yml, is read by the merge job and owned by the humans above. An illustrative shape:

version: 1
review_agents:
  - identity: review-bot[bot] # separate GitHub App; verdict emitted as a check or issue comment
    may: [issue_comment, check:agent-review, label:agent-blocked]
    may_not: [approve, merge, dismiss_review]
merge_authority:
  always_human:
    paths:
      [
        'secrets/**',
        '.env*',
        '**/*.pem',
        'infra/**',
        '**/*.tf',
        '.github/**',
        'services/auth/**',
        'db/migrations/**',
        '*.lock',
        'package-lock.json',
      ]
    required_human_approvals: 1
    two_humans_for: ['infra/**', '.github/**', 'services/auth/**']
  signed_policy_may_merge:
    - class: docs
      paths: ['docs/**', '**/*.md']
      requires: [checks:tests, checks:secret-scan, checks:path-rules]
    - class: tests_only
      paths: ['**/*.test.*', 'tests/**']
      requires: [checks:tests, checks:secret-scan, no_test_count_decrease]
    - class: app_code_small
      paths: ['src/**']
      requires: [checks:tests, checks:secret-scan, checks:diff-ceiling, checks:eval-threshold]
      max_changed_lines: 150
      enabled_since: 2026-09-13
      revert_window_days: 14 # any revert in this window disables the class

Two properties make this a policy rather than a config. The policy file is itself on the always-human list, owned by two teams, so widening it is a reviewed change. And every signed_policy_may_merge class carries a revert_window_days: one revert of a policy-merged PR in that window turns the class off until a human turns it back on. That is Cursor’s ramp, with a floor and a way back down.

The merge job runs as its own identity with the narrowest permission that can merge, and merges only PRs whose touched paths fall entirely inside one enabled class with every required check green. A PR that straddles classes takes the strictest one. No class, no merge.

Cut the self-approval loop: three identity rules

Keeping a review agent from approving its sibling’s PR is an identity problem, and the coordinator makes one bot account for everything look like a convenience.

Rule 1: separate identities per role, none of them owners. The implementer pushes as one GitHub App; the review agent comments as another; the merge job runs as a third. None of the three appears in CODEOWNERS, in any team CODEOWNERS names, or in a bypass list. With “require review from Code Owners” on, a bot outside those owners cannot satisfy the required code-owner review, however many bots you run (docs.github.com).

Rule 2: the review agent’s verdict cannot become an approval. GitHub App pull-request write permission covers review actions rather than exposing a separate “comment but never approve” capability. Do not rely on token scope to cut this loop. Emit the verdict as an issue comment or a neutral agent-review check, keep that check out of the required-success list, and require a human CODEOWNER approval. The agent’s signal may stop a merge; it cannot authorize one.

Rule 3: stale approvals die on push, and the last push needs a human. Turn on dismissal of stale reviews and require approval of the most recent push. A cloud agent that “addresses bot comments” by pushing after a human approved has, under those two settings, reset the approval. Without them, an approval at 6 p.m. covers whatever the agent pushed at 2 a.m.

The dashed loop is the one the identity rules remove: the review agent’s verdict never becomes an approval.

One more loop, quieter than approval: the implementer, subscribed to its own PR, replies to the review agent’s comments, the review agent re-reviews the reply, and both are billed by the token. Cap it as the sibling on CI fix loops caps retries: three review rounds per PR, then a needs-human label and silence.

Novee’s Black Hat 2026 findings (Aug 5–6, 2026) sharpen the point: their Claude Code Action finding (CVE-2026-54316) was a command injection through a GitHub workflow context, and their mitigations include treating workflow-written files as untrusted and preferring deterministic gates. A review agent inside CI reads pull-request text as input; treat it as untrusted, and never let the review job hold a token that can merge. The Claude Code Action repository is the reference shape; your branch rules, rather than the action, decide whether its verdicts count.

Signed policy: how “review less” becomes a rule instead of a habit

“Signed” means three things here, none of them cryptographic. The policy file lives in the repository. Named human teams own it in CODEOWNERS. Every widening is a reviewed pull request with an author and an approver in the log.

Widen on evidence, in this order:

1. Docs and comments after the review agent has run two weeks with a false-positive rate under the bar below.
2. Test-only changes, with a no-test-count-decrease check, after four weeks and zero reverts.
3. Application code under 150 changed lines, gated by the scope eval, after eight weeks, zero reverts, and a comment-acceptance rate above the bar.
4. Never the always-human list. Not after a quarter, not after a year.

Narrow on any of: a revert of a policy-merged PR, a secret-scan hit in any agent PR, a false-positive rate over the bar for two weeks, or a model or prompt change behind either agent. A model swap resets the clock to step one; the reviewer you measured is no longer the reviewer you have.

Measure the reviewer: comment acceptance and false-positive rate

A review agent with no quality number is a linter you cannot tune. Two numbers, computed weekly per repository, are enough to run the ramp above; a third keeps them honest.

Metric	Definition	Starting bar (illustrative)	Action when missed
Comment acceptance rate	Share of agent comments that led to a code change, or that a human marked accepted	≥ 35%	Reviewer stays advisory; no widening
False-positive rate	Share of agent comments a human marked “not an issue”	≤ 20%	Two weeks over the bar: narrow one step, tune the rubric
Blocking precision	Share of agent-blocked labels a human upheld	≥ 70%	Under the bar: the agent loses the block, keeps the comment

The marking convention is the whole trick. Humans react to each agent comment with a thumbs-up (accepted) or a thumbs-down (false positive); a nightly job tallies reactions through the API and writes one row per comment. An illustrative shape, needing gh and jq:

REPO="org/repo"; BOT="review-bot[bot]"
gh api "repos/$REPO/pulls?state=closed&per_page=50" --jq '.[].number' | while read -r n; do
  gh api "repos/$REPO/pulls/$n/comments" --jq \
    ".[] | select(.user.login==\"$BOT\") | {pr:$n, id:.id, up:.reactions[\"+1\"], down:.reactions[\"-1\"]}"
done > "/var/log/agent-review/$(date +%F).jsonl"

Compute the rates from the JSONL, plot them weekly, and keep the headline numbers next to the policy file. AWS’s Sep 8, 2026 note on LLM-judge variance applies to reviewers as much as to evaluators: a threshold at the edge of the noise is a coin flip, so give the bars margin and act on the trend rather than the week (AWS).

What breaks, and the signal that tells you

One bot account for everything. The coordinator, implementer, reviewer, and merge job share an identity because it was easier on day one. Signals: PR author and reviewer have the same login; approvals seconds after the PR opens; “dismissed” events by a bot in the timeline. Mitigation: rule 1, applied retroactively, and an audit of every bypass list.

The reviewer learns to say yes. Agent comments drop to near zero on PRs from a sibling agent while staying normal on human PRs. Signals: acceptance rate rising while comments per PR fall; blocking labels vanish. Cause: a shared-context folder where the implementer’s rationale becomes the reviewer’s prior. Mitigation: the reviewer gets the diff and the task card, never the implementer’s notes.

Policy drift by exception. The signed_policy_may_merge block grows a class every sprint and the always-human list loses a path “temporarily.” Signals: policy-file commits by one person; classes without enabled_since; a revert_window_days of zero. Mitigation: two-team ownership, and a monthly diff of the file, read aloud.

Humans stop reacting. The quality numbers go quiet because nobody marks comments, and the ramp widens on stale evidence. Signals: reactions per agent comment trending to zero; acceptance rate frozen. Mitigation: widening requires a minimum reaction count per week, and the approval queue hygiene sibling has the fatigue signals this one borrows.

The review agent reviews itself. A PR that edits the reviewer’s prompt or rubric gets reviewed by the same agent under the new prompt. Signal: rubric changes merged without a human comment. Mitigation: prompt and rubric paths sit under .github/, so they are always human.

Review policy is operating-layer infrastructure

None of this is a prompt. You can tell a review agent “never approve,” and it will comply until the day the merge job counts its comment as consent. The controls live in the layer that outlasts the model swap: narrow identities, a policy file humans own, branch rules that ignore bot approvals, and two numbers on a page. That is the command center’s job in this corner of the fleet: not smarter agents, a desk where the rules run whether or not the agents are having a good night.

The record is the other half. Every agent comment, human reaction, policy-merged PR and revert should be readable a month later, in order, so tightening a class has a reason attached. The evidence discipline that lets you replay what a fleet did is what makes “review less” defensible, and the agentic CI/CD pipeline around it is where the record gets written.

FAQ: AI PR review agent policy

Should an AI PR review agent be allowed to approve pull requests?

No. Let it read, comment, suggest, and block. Approvals that count toward branch protection should come from named humans in CODEOWNERS or from a merge job acting on a signed policy that lists the path classes it covers. Keep every bot identity out of owner teams and bypass lists so its approval satisfies nothing.

Which files should an AI agent never merge?

Secret and credential paths, lockfiles and dependency manifests, infrastructure modules, CI and workflow config (including the policy file itself), auth and crypto code, and data migrations. Put them in CODEOWNERS under human teams, require code-owner review, and treat any agent edit there as a change a person reads.

How do you measure whether an AI code review agent is any good?

Track comment acceptance rate (comments that led to a change or a human “accepted”), false-positive rate (comments marked “not an issue”), blocking precision, and review rounds per PR. Tally them weekly per repository from reactions and thread outcomes, give the thresholds margin, and widen or narrow the agent’s scope on the trend.

Sources

• Cursor blog: “Introducing Projects” (Sep 10, 2026)
• Cursor changelog: “Cursor Projects” (Sep 10, 2026); “Cloud Agents and Cursor Harness Improvements” (Aug 19, 2026)
• GitHub Docs: CODEOWNERS, required reviews, rulesets, GitHub Apps and permissions
• anthropics/claude-code-action on GitHub: an agent that runs in GitHub Actions and comments on pull requests
• Novee: “Critical flaws in Anthropic, Google and OpenAI’s coding agents” (Black Hat 2026, Aug 5–6, 2026)
• AWS Machine Learning Blog: “Automated agent evaluation with Amazon Bedrock AgentCore and GitHub Actions” (Sep 8, 2026)