Avoid it where you can. Separation of duties means the person who starts or pushes a change should not be the only one who approves it. For bot opened fix pull requests, require an approval from a person who did not trigger or push the change, and enforce it in branch protection.
What the concept means
Separation of duties is a long-standing control idea: split steps of a sensitive process so that no single person can complete it alone. In software delivery, it usually shows up as requiring a second reviewer for changes that reach production.
With bots, the confusion is who counts as the author. If an engineer clicked a button to create the fix pull request, or pushed a commit to the bot branch, they are plausibly the author for control purposes.
What branch protection can enforce
GitHub's protected branch documentation describes several relevant settings:
| Setting | Effect |
|---|---|
| Required approving reviews | A set number of approvals before merge |
| Review from code owners | Owners of affected code must approve |
| Approval of the most recent reviewable push | Someone other than the pusher must approve the latest push |
| Dismiss stale approvals | New changes require fresh approval |
| Required status checks | Checks must pass before merge |
The most recent push option fits this case well. If a developer adds a commit to the bot's branch to fix a test, someone else has to approve that final state.
A practical rule
- A bot or tool opens the pull request.
- A person other than any pusher approves, plus code owners.
- Stale approvals are dismissed on new commits.
- The merge happens by a rule or a person, with the approval recorded.
If a small team cannot meet this, write down compensating controls, such as post merge review within a day. Auditors usually care that the control is defined and followed, so ask yours what evidence they expect.
Interaction with automatic merging
If you use rule based automatic merging, the rule itself acts as a control. Make sure someone other than its author approved the rule, and that rule changes are reviewed. See approval tiers by change type.
What to show an auditor
Keep the branch protection settings exported or captured on a schedule, a sample of merged fix pull requests with their approvers, and the written rule for who may approve what. Evidence that the setting was on during the whole period matters more than a single screenshot. Ask your auditor which format they prefer before the period starts.
Where Safeguard fits
Safeguard's autonomous remediation ships off by default with every category on Manual, policies and gates can encode merge rules, and compliance and evidence automation helps collect approval records. This is not an audit opinion. A free scan is a way to start.
Quick check
Does a bot approval count?
Treat a bot approval as a check, not a human review, unless your policy says otherwise.
What if we have two engineers total?
Use the most recent push rule so each reviews the other's work, and document it.
Sources
Last reviewed: 19 October 2026.
