Executing Workflows Should Be a Permission, Not a Default

TL;DR

• GitHub shipped workflow execution protections to general availability on September 17, 2026, completing an allowlist model for who and what can start an Actions workflow (changelog).
• GA adds workflow file targeting, Insights, and a REST API — the policy is now manageable as code.
• GitHub also announced a default rule that disables pull_request_target for public repositories without an existing event policy, enforced automatically on November 2.
• Netics' reading: this is the trigger half of the CI/CD boundary — the workload-identity half already exists; now the who starts it half has an owner.
• Practical move: use evaluate mode now to inventory which workflows genuinely need pull_request_target, before enforcement starts.

The trigger was always the weakest pre-run control

On September 17, GitHub moved workflow execution protections out of public preview: for GitHub Enterprise, organizations, and repositories, you can now define an allowlist of who may trigger a workflow (actor rules) and what events can start it (event rules), evaluated before a run begins. Three additions matter as much as the GA itself: workflow file targeting scopes rules to specific files, so deploy.yml can be restricted to a designated team while regular CI stays open to contributors; Insights shows how rules evaluate and enforce so policy can be tuned before it bites; and a REST API exposes the whole thing as code, which is what makes this governable across hundreds of repositories instead of being a settings click.

The security argument for this is older than the feature. Executing a workflow is the moment your pipeline runs code with your secrets, your permissions, and your runners. Yet for most of Actions' life, the decision of "what runs" lived in workflow files written by whoever could push a branch — including a stranger opening a fork. Execution protections move that decision to a policy layer that exists before the run, which is a different kind of control than anything inside the YAML.

The pull_request_target default is the real news

The headline change is the default. GitHub's own changelog identifies pull_request_target workflows — the Pwn Requests family — as among the most commonly exploited vulnerabilities in action workflows. The trigger runs with access to your secrets in the context of the base repository, so if code executes from a fork, untrusted code can poison the pipeline and exfiltrate secrets. For public repositories that do not already have an applicable event policy, GitHub is introducing a default rule that disables pull_request_target. It does not apply to private or internal repositories, and it initially runs in evaluate mode: you can see which workflow runs would be affected before enforcement begins.

Then the deadline: on November 2, 2026, GitHub will automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before GA.

Workflow execution is a permission boundary, not a YAML detail

This is the piece teams usually skip. A compromised token, a malicious dependency, or a careless workflow_dispatch input can all trigger your pipeline — execution protections do not stop every one of those paths, but they force the question into the open: is this run something an actor and an event were explicitly allowed to start? Two workflows in the same repository can now carry different policies, and a production deploy can be restricted to a named team while a lint job stays open. That per-workflow granularity is what makes the feature usable rather than a repo-wide blunt instrument.

Beware the quiet part: an execution-protection rule only matters if the event it gates is the only path in. If a workflow is also triggerable via workflow_dispatch, a manually-activated run bypasses nothing per se — but your actor rules still decide who may click the button. The allowlist is the control; the event is the surface. They have to be reviewed together, and the REST API finally makes that review something a pipeline can check.

What to do before November 2

Three moves, in order. First, enable evaluate mode on the new default and read Insights to see which of your public workflows would fail — this is the cheapest inventory you will ever get, and it costs nothing to run. Second, separate production workflows from CI workflows with file targeting now, so a future policy change cannot take the build down with the deploy. Third, for every workflow that genuinely needs pull_request_target, write an explicit event policy that names it, with a comment explaining the safe usage pattern (checking out the PR ref is the classic mistake; the base ref is the safe one). After November 2, GitHub enforces the default for you — the teams that prepared will not notice; the teams that did not will discover it in a red build on a Monday.

The larger lesson is the one this blog keeps coming back to: CI/CD security is a set of boundaries, not a pile of tools. Workload identity gives the runner a verifiable identity (we argued the boundary last year); execution protections now give the trigger an owner. One half answered who the runner is; this half answers who can start a workflow, and with which event. That completes the loop on the trigger side — and it is a reminder that the same review belongs in every other automation platform you run.

Netics helps engineering teams map these boundaries before the deadline does it for them: which workflows can execute, who can trigger them, and what the enforcement calendar looks like. Start from the Netics homepage for a practical review of your CI/CD policy surface.

Sources

• Workflow execution protections in GitHub Actions generally available — GitHub Changelog, September 17, 2026.
• GitHub Actions holds potentially malicious workflows for approval — GitHub Changelog, July 28, 2026.
• About Actions policies — GitHub Docs, accessed September 22, 2026.
• Preventing Pwn Requests — GitHub Security Lab, accessed September 22, 2026.

Source: "Workflow execution protections in GitHub Actions generally available" — github.blog, September 17, 2026.