Leave it off by default. GitHub has a setting that lets workflows create and approve pull requests, and for repositories in a personal account it is off. Turn it on only for a specific, reviewed workflow, and never let a workflow both open a change and count as its approver.
What the setting is
In the repository Actions settings, under workflow permissions, there is a checkbox named Allow GitHub Actions to create and approve pull requests. GitHub's repository settings documentation says that by default workflows are not allowed to create or approve pull requests for repositories in a personal account, and that organization repositories inherit the organization's setting.
GitHub's security guidance explains why the option deserves care: such automation could be a security risk if the pull request is merged without proper oversight.
The risk in plain terms
A required approval is a second pair of eyes. If a workflow can approve, the approval can come from automation instead of a person. Suppose a compromised action runs in a workflow that has this permission. It could open a pull request with a malicious change, approve it, and, depending on your rules, get it merged. The human check disappears.
Even without malice, a workflow that creates a pull request can create a quiet drift: changes appear, the checks pass, and nobody reads them.
Two different permissions
People often mix these up.
| Capability | Why you might want it | Risk |
|---|---|---|
| Create pull requests | Update bots, generated files, release notes | Lower: a human still reviews |
| Approve pull requests | Rarely justified | Higher: replaces the human check |
The setting in GitHub pairs the two, so think about whether you need creation, and then whether the pairing is acceptable. If a workflow needs to open pull requests, a narrow alternative is a dedicated app or token whose only job is creation, with branch protection that still demands a human approval.
How to decide
- Inventory workflows that open pull requests. Name the purpose of each.
- For each, ask whether a person reviews the result before merge. If yes, creation alone is fine.
- Check branch protection or rulesets. Require at least one approval from a person, and consider requiring review from code owners for sensitive paths.
- Confirm that approvals from the workflow identity do not count toward required reviews, or do not enable approval at all.
- Put the setting at the organization level, so repositories inherit a safe default and exceptions are visible.
- Review the permissions in those jobs. A job that opens a pull request needs write access to contents and pull requests, and nothing else.
What to log
Record which repositories have the setting on and why. If an auditor asks how you prevent a single actor from authoring and approving a change, you want a clear answer that does not depend on remembering a checkbox. Treat the answer like any separation of duties control. See PCI DSS 6.5.1 change control for how reviewers think about it.
Quick check
Is it fine for a bot to open dependency update pull requests?
Yes, if a person reviews and merges them under normal branch protection. Opening a pull request is different from approving one.
Where do organization repositories get this setting?
GitHub's documentation says organization repositories inherit the organization's setting, so set the safe default there.
Sources
Last reviewed: 19 October 2026.
