Author Never Approver: Enforce Segregation of Duties in Code, Not Policy

At Ramp, ~30% of all pull requests merged to their frontend and backend repos are now written by their Inspect agent. No written policy gets checked thousands of times a month; at that volume the author-never-approver rule survives only if the platform makes the bad outcome impossible rather than asking a human to remember it. This sits alongside the other gates in this section: review as a gate, AI reviewing AI, and auto-approval by risk.

The control is one rule: the entity that authored a change cannot approve that change. Two platforms built on opposite identity models reach it the same way. GitHub's Copilot cloud agent commits as Copilot; Ramp's Inspect opens pull requests under the prompting human's own GitHub token. The policy version of the rule is a sentence in a handbook. The platform version is a permission that does not exist, and only the platform version survives AI volume.

GitHub closes both halves: the bot can't approve, and neither can the requester

GitHub's risks-and-mitigations documentation for Copilot cloud agent enforces the split twice over. First, the agent itself is locked out of the approval path: Copilot creates draft pull requests, "cannot mark its pull requests as 'Ready for review' and cannot approve or merge a pull request." A human with write access must do all three.

Second, and less obvious: the human who asked for the change is treated as an author, not a bystander. Copilot's commits name the requesting developer as co-author, and GitHub "prevents the user who asked Copilot cloud agent to create a pull request from approving it," explicitly to preserve the "Required approvals" branch protection rule. Prompting the agent is authorship. The approver has to be a third party.

The same logic extends to scheduled and event-triggered runs, where no human initiates each task. Work from a Copilot automation is attributed to the user who created the automation, and that user cannot approve the resulting pull requests either. Accountability follows the standing instruction, not just the live prompt.

Ramp gets the same control from the opposite identity choice

Inspect's authors state the failure mode plainly. They recommend opening pull requests with the user's own token rather than as the app itself, because the app-identity route "would allow for any user to approve their own changes. You do not want to knowingly create a vector for unreviewed code to go into the codebase."

The mechanism is worth tracing. If the bot is the PR author, then every human is eligible to approve, including the human who prompted the change. GitHub's native rules only block authors from approving their own PRs; a PR authored by an app has no human author to block. By putting the prompting human's identity on the PR, Ramp makes GitHub's standard own-PR restriction do the segregation work automatically. GitHub solved the same hole the other way, keeping the bot as author but adding the requester to the blocked set.

Two identity models, one invariant: whoever caused the change, human or synthetic, is disqualified from approving it. How the actor's identity gets constructed in the first place is the upstream question in this same section. See agent identity and binding to the human, the assigning-work pages this gate depends on.

The documented escape hatch is the control's weak point

GitHub's own docs note that rulesets incompatible with Copilot, such as a rule allowing only specific commit authors, block the agent entirely, and the documented fix is to "add Copilot as a bypass actor." A bypass actor is exactly what it sounds like: an identity exempted from the rules. Every team that grants it should treat the grant as a control exception with an owner and a review date, not a setup step. The tradeoffs are covered in when branch protection blocks the bot.

Neither source settles whether an AI may be the approver, or who approves at deploy

Both GitHub and Ramp enforce the split at merge and stop there. Neither addresses whether an AI reviewer can be the approving party for AI-authored code, which is the question Intercom's auto-approval numbers force: 19% of Intercom's PRs are now auto-approved with no human in the loop. That argument lives in AI reviewing AI and review as a gate. Both sources are also silent on deploy-time approvals: they govern who may approve a merge, and say nothing about who may promote the merged change to production.

Check it against the broader segregation-of-duties property your auditor will ask about.