To require human review for bot pull requests, protect your main branch so that every change must arrive by pull request, needs a set number of approving reviews, must pass required status checks, and asks code owners for review. Then turn off the options that let people or tools bypass those rules.
TL;DR: The branch is the gate. Set the gate once, and it applies to everyone, including automated fixes. The rules are the same whether a human or a bot opened the pull request, which is exactly what you want.
Definition: A protected branch is a branch, usually your main one, with rules that limit how changes can reach it, such as requiring reviews or passing checks.
Why set rules at the branch and not in the tool?
Automation tools can have their own settings, but a branch rule is stronger for three reasons. It applies to every author, so you do not need a separate policy for each bot. It is enforced by your code hosting platform, not by a tool that might be misconfigured. And it leaves one place to look when an auditor or a new teammate asks, "who can change production code?"
This post uses GitHub as the example because its documentation is public and clear. Other code hosting platforms have similar features under different names, so check yours.
What can a protected branch require?
GitHub's documentation lists a set of rules you can apply to a protected branch. The most useful for bot pull requests are below.
| Setting | What it does | Why it helps with bots |
|---|---|---|
| Require pull request reviews before merging | Requires a set number of approving reviews from people with write permission, or from a designated code owner | A bot cannot approve its own change |
| Require status checks before merging | Required checks must have a successful, skipped, or neutral status before merging | Tests run on every bot change |
| Require conversation resolution | Open comments must be resolved before merging | Questions get answered |
| Require signed commits | Commits must carry a verified signature | You can tell who or what authored a change |
| Require linear history | Keeps the history in a simple line | Easier to read and to revert |
| Require merge queue | Changes merge one at a time after checks | Stops conflicting changes landing together |
| Restrict who can push | Limits who can push to the branch | Closes the side door |
| Do not allow bypassing the above settings | Applies the rules to administrators too | Closes the biggest loophole |
The documentation also explains that when required reviews are on, collaborators can only change a protected branch through a pull request that is approved by the required number of reviewers.
What are the steps to set this up?
- Pick the branches that matter. Usually that is main, plus any release branches.
- Turn on required pull request reviews. Start with one approving review. Use two for critical repositories.
- Add required status checks. Choose your tests, your build, and any security checks. If you pick an expected source for a check, only that source can satisfy it.
- Create a CODEOWNERS file. GitHub documents that a CODEOWNERS file can sit in the .github folder, the root, or a docs folder, and that code owners are automatically asked to review pull requests that change files they own.
- Require code owner review. People with admin or owner permissions can require code owner approval before merge.
- Close the bypasses. Turn on the option that stops people from bypassing the settings, and limit who can push directly.
- Test the rules. Open a harmless pull request from a test account or a test bot and confirm it cannot merge without review.
- Write it down. Put the rules in your engineering handbook so the reasoning is not lost.
For a longer walkthrough, see how to configure GitHub branch protection rules.
How do code owners help?
A code owner is a person or team who is responsible for certain files. A CODEOWNERS file lists them. The people you choose must have write permission, and a team chosen as a code owner must be visible and have write permission.
For fix pull requests, code owners solve a practical problem. A security fix might touch a payment library one week and a logging library the next. With code owners, the right people are asked to review each one without anyone having to remember who owns what. GitHub notes that code owners are not automatically requested to review draft pull requests, and they are notified when a draft is marked ready for review.
What mistakes make the gate leaky?
Be careful about these patterns.
- Administrators can bypass. If the setting that stops bypassing is off, an administrator account or a token with admin rights can merge without review.
- A shared service account approves everything. If one account approves bot changes automatically, you have a rubber stamp, not a review. Keep approvals tied to real people.
- Checks that are optional. If a check is not required, a red result does not stop a merge.
- Skipped checks. The documentation notes that a skipped status counts as passing for required checks, so make sure a skipped check does not hide a missing test.
- Too many reviewers, too little time. A queue of unread pull requests encourages quick approvals. Control volume at the source.
What does a worked example look like?
This example uses invented numbers to show how rules combine.
Worked example (invented numbers): A team has 8 repositories and uses an automated tool that opens about 10 fix pull requests a week across them. They want every fix reviewed by a person who owns the code.
| Rule | Setting | Result |
|---|---|---|
| Required reviews | 1 approving review | A person must click approve |
| Code owner review | On for all 8 repositories | The right team is asked automatically |
| Required status checks | Build, unit tests, security checks | A red check blocks the merge |
| Bypass | Turned off for administrators | Nobody skips the rules |
| Signed commits | On | Authorship is verified |
In week one, 10 pull requests arrive. Seven are approved after a short look. Two get a comment asking for a smaller change. One is closed. At no point can a bot merge by itself, because the rules require a person's approval.
The team also checks the results monthly: how many pull requests were approved, how long approval took, and whether any merged without a code owner. Those three numbers tell them whether the gate is working in practice and not only on paper.
How does review connect to automation settings?
Branch rules and fix settings work together. Fix settings decide when a pull request is prepared and how bold it is. Branch rules decide whether it can merge. You want both. For the thinking on who should review what, read human review gate for AI generated fix pull requests. For the larger picture on why automation starts off, read why are automated vulnerability fixes off by default.
How does Safeguard fit with branch rules?
Safeguard provides autonomous remediation with fix pull requests as a generally available capability. Fixes arrive as pull requests, so the branch rules described above apply to them like any other change. Fix pull requests are off by default, and every category is set to Manual, so nothing opens automatically until your team turns it on.
Safeguard also provides policies, gates, and guardrails, which let your team set rules for what can ship, and the demo below shows a pull request being gated. To see what your project contains and which findings have fixes available, run the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a pull request is held until required checks pass, and notice that the same rule would apply whoever opened it.
Quick check
Can a bot approve its own pull request?
It should not. Required reviews are meant to come from people with write permission or from code owners. Keep approvals tied to real people and avoid shared accounts that approve everything.
Do branch rules apply to administrators?
Only if you turn on the option that stops bypassing the settings. Otherwise administrators may be able to skip them. Check this setting first.
What counts as a passing status check?
GitHub documents that required checks must have a successful, skipped, or neutral status. Make sure a skipped check is not hiding a missing test.
Do I need this if I only use a few repositories?
Yes. The setup is small, and it protects you from mistakes by tools and people alike. It also gives you a clear answer when someone asks who can change production code.
Sources
- About protected branches, GitHub Docs, on required reviews, status checks, and bypass settings.
- About code owners, GitHub Docs, on CODEOWNERS files and automatic review requests.
Last reviewed: 19 October 2026.
