A Pull Request Review Gate Sits After the Write
A pull request review gate guards the merge, but opening the pull request already needed write access. Five gaps to audit and what a patch file changes.
Quick Answer
A pull request review gate protects the merge, not the write. To open a pull request an agent needs a credential that can push a branch, so side effects such as triggered workflows, preview deployments and stale approvals can happen before a human reads the diff. Keep the review but move the gate earlier by narrowing the token, or have the agent hand over a patch file instead.
The usual answer to AI agent safety is a pull request review gate. The agent proposes a change, and a human reviews it before anything merges. We think that answer is true and incomplete. It describes the review, and it says nothing about the access the agent needed to make the proposal.
In this post we separate the review surface from the access level, list the ways a write credential does more than its owner intended, and explain what a patch file changes and what it does not. We also say when opening the pull request remains the right trade.
A Review Surface and an Access Level Are Different Things
The review surface is the diff a person reads and the judgement they apply to it. The access level is what the agent's credential may do at the moment it produces that diff. Teams tend to treat the two as one thing, and we think that is where the safety assumption quietly breaks.
Most of us picture a pull request as a passive container, a note that says please look at this. It is not. It is the visible end of a chain of write actions, and the human gate sits at its last link, which is one step later than most people picture.
Opening a Pull Request Already Needs Write Access
GitHub's REST documentation states the requirement plainly. "To open or update a pull request in a public repository, you must have write access to the head or the source branch," says the pull requests API reference. The credential an agent uses to propose a fix can therefore create branches and push commits.
We think that detail matters because a pushed branch is not inert. Continuous integration, preview environments and bots all react to pushes. By the time a reviewer opens the diff, the agent has already acted inside the repository, and the review only decides what happens next.
Pull Request Review Gates Leave Five Gaps Around the Write
These are concrete, checkable ways a write credential ends up doing more than the person who granted it intended. We would audit each of them before giving any agent the ability to push.
1. Workflows That Run on Every Push
GitHub's documentation says the push event "runs your workflow when you push a commit or tag," and that this includes workflows that are not merged into the default branch. Any job triggered by push therefore runs when the agent pushes its branch, before a human has looked at a single line.
2. Approvals That Survive New Commits
Branch protection has a setting named "Dismiss stale pull request approvals when new commits are pushed." When it is off, an approval given to one commit can remain attached after the branch changes. We would switch it on for any repository an agent can push to.
3. Protection That Stops at the Main Branch
Strict rules on main say little about the sibling branches an agent creates. If those branches deploy previews or reach a shared staging environment, the agent has reached production-adjacent systems without touching the protected branch.
4. Bot Scopes That Grow Over Time
A bot identity created to open pull requests tends to collect access to more repositories over the years. A token meant for one repository that can write to dozens turns a single compromised workflow into a wide blast radius.
5. Merge Automation Tuned for Humans
Where auto-merge is enabled, a change that passes checks can merge as soon as its conditions are met. Those rules were written with human authors in mind, so we would read them again with an agent author in mind.
| Gap | What to check | Where the check lives |
|---|---|---|
| Push-triggered workflows | Which jobs run on any branch push | Workflow files |
| Stale approvals | Dismissal on new commits is enabled | Branch protection rules |
| Sibling branches | Which branches deploy or preview | Deployment and environment settings |
| Bot scopes | Repositories the token can write to | Token or app installation settings |
| Auto-merge | Conditions that merge without a person | Repository rules |
We would run this table as a quarterly audit rather than a one-time review. Repositories gain workflows, branches and integrations constantly, and each addition can reopen a gap that was closed last time. The cheapest habit we know is to re-read the push-triggered workflows whenever a new bot or agent identity is created, because that is the moment the access level changes.
The pattern is the same in every row. The control lives in configuration written before agents existed, and nobody revisits it when an agent receives a token.
Reviewer Fatigue Weakens the Gate Further
A review gate works only while the reviewer is reading. A design that produces more pull requests eventually erodes the attention each one receives, and we would expect a queue of plausible agent-written changes to invite faster approvals than one carefully written fix.
Our analysis of incidents per pull request in the AI productivity data looks at what rising throughput does to stability. The relevant point here is narrow. If your safety model depends on human judgement, the throughput at which that judgement degrades is part of the model.
Earned Trust Is a Sensible Gate With One Weak Spot
A fair alternative to human review is to let agents earn execution rights through a record of success at each stage. We think that is stronger than gating on an agent's own confidence score, because a confidence number comes from the same process whose reliability is in question.
Its weak spot is production itself. An incident is usually a case the system has not seen, or a failure that slipped past existing safeguards. A track record built on yesterday's incidents is the weakest evidence for the one happening now, so we would use it to widen autonomy slowly and never as the only gate.
What a Patch File Changes and What It Does Not
There is a way to keep the review and drop the write. If an agent outputs a patch file instead of opening a pull request, a person applies it and opens the pull request under their own identity. The diff is still reviewed and the audit trail still exists. The one thing removed is the agent's write credential.
That is the property we care about when we keep production credentials read-only. The agent can read logs, databases and repositories to build its evidence, and it never holds the means to change them. Our piece on root cause analysis without write access to production explains the same boundary from the investigation side.
A patch file is not magic. The reviewer still has to read it, and a bad patch applied by a tired person is still a bad change. What it removes is the side effects that happen before anyone looks.
When Opening the Pull Request Is the Right Trade
The cost of a patch is friction. For a one-line fix on a Friday afternoon, applying a file by hand is more work than clicking merge on an open pull request, and some teams will reasonably decide that convenience is worth it.
We think that trade is defensible when three conditions hold. The token is scoped to one repository, no workflow with secrets runs on push to that repository, and stale approvals are dismissed automatically. If you cannot say yes to all three, the patch file is cheaper than the audit.
Five Questions to Ask Before Granting the Token
We would put these questions to the team before an agent receives any credential that can push.
- What can the agent's credential do right now, across every repository?
- Which workflows run the moment the agent pushes a branch, before a person sees it?
- Does the repository dismiss approvals when the agent pushes a new commit to an open pull request?
- How many agent-written changes does a reviewer see in a week, and is review time falling?
- If the same diff arrived as a file instead of a branch, what would we lose, and is it worth the token?
For a related view of how verification limits what an agent should be allowed to do, see our notes on agentic database changes and verification risks.
Move the Gate Back to the Write
A pull request review gate is a good control for the merge and an incomplete one for the agent. Narrow the token, audit what runs on push, dismiss stale approvals and decide on purpose whether the agent needs write access at all.
We chose the patch file for the same reason. Operate can't commit, open pull requests, merge, or deploy, and it generates a .patch file that an engineer reviews and applies manually.
Frequently Asked Questions
We think it depends on the credential. If the token is scoped to one repository, push-triggered workflows are locked down and stale approvals are dismissed, a pull request is a reasonable handover. Without those controls, a patch file gives the same review with no write access held by the agent.
We treat it as a review control at the merge, not a security boundary. It lets a person read a diff before the change lands. It does not stop actions that happen earlier, such as workflows triggered by the push that created the branch.
Only if the repository allows it. GitHub offers a setting that dismisses stale approvals when new commits are pushed, and we would enable it for any branch an agent can write to. Otherwise an approval can outlive the change it was given for.
We read GitHub's documentation as requiring write access to the source branch, which means the ability to push commits. That is why we describe a pull request as a write action. A credential that can only read cannot open one.
We use it to mean a person approves each consequential action before it takes effect. The loop only protects you if the approval happens before side effects, so we place the person ahead of the write, not only ahead of the merge.
About the author
Operate Team
The team behind Operate
Operate Team builds Operate, enterprise AI agents for production operations. Operate answers production questions from Slack and Microsoft Teams, investigates alerts, and reviews performance, security and cost. It finds the root cause with evidence and proposes a fix for an engineer to review, with controlled access to your systems.
