Why should GitHub Actions be prevented from approving pull requests?

GitHub Actions should be prevented from approving pull requests because a workflow that can both test and approve changes can be manipulated to rubber-stamp malicious code. If the workflow is triggered by untrusted input, an attacker may influence the approval path or bypass human review. Keep approval authority separate from automation and restrict workflow permissions tightly.

Why approval authority should stay separate from GitHub Actions

Approval is a trust decision, not just a workflow step. If the same automation that validates code can also approve it, the control stops being independent and becomes easy to steer through crafted inputs, malicious pull request content, or workflow logic that is triggered before a human reviewer sees the change. That breaks the separation that makes code review meaningful.

GitHub Actions can process repository events, parse files, read metadata, and act on inputs that may be influenced by contributors or external actors. When approval authority is embedded in that same execution path, the workflow can accidentally bless code it should only inspect. The safer pattern is to let automation gather evidence, then require a separate reviewer or policy gate to make the approval decision.

For repository security, that separation matters because approval often unlocks merge, deployment, or privileged follow-on actions. A workflow that can approve its own findings creates a trust loop: the same path that verifies the change also decides whether the change is acceptable. In practice, that is the kind of design that turns a review helper into an enforcement bypass.

How an attacker can abuse an approval-capable workflow

When a pull request workflow has access to approval logic, the attacker does not need to defeat the whole system. They only need to influence the conditions that drive the approval path. That may happen through untrusted branch content, changed workflow files, manipulated inputs, or a logic branch that treats automated checks as equivalent to human review. The result is a rubber-stamp effect, where malicious code can be advanced with less scrutiny than intended.

This is especially dangerous when the workflow also has repository permissions, token access, or visibility into secrets and build outputs. Even if those permissions are limited, the approval step can still be abused to normalise a bad change, obscure review accountability, or make a malicious change look policy-compliant. The attack path is less about breaking cryptography and more about bending process trust.

Operationally, the failure mode is often subtle: teams assume the workflow is only “helping” with review, but the automation starts to shape the decision itself. That is why approval and evaluation should be split across different identities, different permission scopes, and ideally different trust boundaries.

What secure handling looks like in practice

The cleanest model is to let GitHub Actions analyse, test, label, or report, but never approve. Human reviewers or a separate protected policy mechanism should own approval. Keep workflow permissions minimal, disable unnecessary write capabilities, and treat pull request content as untrusted until it has passed review under controlled conditions.

Where automation is needed, use it to produce evidence rather than decisions. For example, let the workflow surface test results, dependency diffs, or policy checks, then require a distinct approval path that cannot be influenced by the same event payload. If the workflow must interact with pull requests, restrict it so it cannot approve changes, merge code, or elevate itself through repository-side configuration.

It also helps to anchor this design in your broader repository control model, including branch protection, code ownership, and workflow permission boundaries. NHIMG’s GitHub and GitHub Actions Security Guide covers the surrounding hardening patterns, while the CI/CD Pipeline Identity Security Guide explains why approval authority, token scope, and untrusted builds should not live in the same trust chain.

Risk and Threat Considerations

If automation can approve pull requests, the main risk is control collapse: the reviewer and the reviewed path become the same thing. That creates an integrity gap where malicious changes may be promoted because the workflow was designed to trust its own outputs too much.

Failure mechanism: An attacker influences the workflow input, approval condition, or repository logic so the automation emits an approval that should have required independent human judgement.

Impact: Malicious code can be merged or deployed with a false sense of review assurance, increasing the chance of supply-chain compromise, secret exposure, or downstream persistence in the repository and release process.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V15 — Secure Coding and Architecture	Workflow approval separation is an architecture trust-boundary issue.
Recommendation — Separate evaluation logic from approval authority and enforce independent review paths.
CIS Controls v8	CIS-5 — Account Management	Repository automation permissions and approval rights depend on tightly scoped accounts.
Recommendation — Restrict automation accounts so they cannot approve or merge pull requests.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	GitHub Actions should not hold approval authority if it only needs validation access.
	IA-5 — Authenticator Management	Workflow tokens and credentials must be controlled so they cannot be reused for approval abuse.
	AU-2 — Event Logging	Approval-capable automation needs auditability to show who approved and why.
Recommendation — Limit workflow permissions to the minimum needed and remove approval capability. Rotate and scope workflow credentials so they cannot be used to self-approve changes. Log approval actions separately from workflow test results for review and detection.

Practitioner Guidance

What to verify: Confirm that no GitHub Actions workflow has permission to approve pull requests, merge changes, or bypass branch protection, even indirectly through reusable workflows or repository automation settings.

Decision rule: If a workflow can observe the change and influence the release decision, treat that as a separation-of-duties failure and remove approval capability before expanding automation further.

Common mistake: Teams often allow a “read-only” checker to grow into a policy actor over time. The boundary should be explicit: automation can advise, but it should not decide its own trust outcome.

Practitioner takeaway: Approval must remain independently attributable; once a workflow can approve what it also evaluates, you have turned review into self-authorization.