# GitHub Actions can now block who or what starts a workflow — and `pull_request_target` is getting a secure default GitHub has made Actions workflow execution protections generally available, adding per-workflow targeting, audit insights and REST policy management while preparing to disable `pull_request_target` by default for affected public repositories on November 2. GitHub Actions now has enforceable actor and event rules before a workflow starts, plus a coming default block for a trigger that can expose repository secrets to untrusted fork code. - Status: Active - Published: 2026-09-18T16:30:11+12:00 - Updated: 2026-09-18T16:30:11+12:00 - Categories: Web Development, Cloud & Infrastructure, Deployment & DevOps, Developer Tools - Tags: CI/CD, GitHub, GitHub Actions, supply chain security - Canonical HTML: https://beyondthe.news/dossiers/github-actions-execution-protections-pull-request-target-default-block ## What changed GitHub Actions workflow execution protections are now generally available for enterprises, organizations and repositories. Policies can allow or block workflow execution based on the actor and triggering event, and GA adds rules scoped to individual workflow files, an Insights surface for observing policy decisions and REST endpoints for managing the protections as code. GitHub is also introducing a default event policy for public repositories that disables `pull_request_target` when no applicable event policy already exists. The rule begins in evaluate mode and, for affected repositories using the default policy, is scheduled to become enforced automatically on November 2, 2026. ## Why it matters GitHub is moving an important CI security boundary from workflow-by-workflow convention into a platform policy layer that runs before a workflow starts. `pull_request_target` is particularly risky because it executes in the base repository context and can have access to secrets even when the change originates from a fork. Teams can now shadow-test rules, target especially sensitive workflows such as deployments, and manage policy across repository fleets rather than relying only on YAML review and contributor discipline. ## Execution policy now sits in front of the workflow Actor rules control who may start a workflow and event rules control which triggers may start it. GitHub evaluates both before execution. That makes the policy independent of logic inside the workflow file and gives organizations a separate enforcement boundary for sensitive automation. ## GA adds workflow-specific rules and policy-as-code Rules can now target particular workflow files, so a repository can apply stricter controls to a deployment or release workflow without imposing the same restrictions on ordinary CI. GitHub also exposes Insights for seeing how rules evaluate runs and REST endpoints for creating, reading, updating and deleting protections at enterprise, organization and repository scope. ## The `pull_request_target` default changes on November 2 For public repositories without an applicable event policy, GitHub is rolling out a default rule that disables `pull_request_target`. It starts in evaluate mode so maintainers can inspect the workflows that would be affected. On November 2, 2026, GitHub says it will automatically enforce the default for affected repositories that were using the default `pull_request_target` policy before GA. ## Maintainers can explicitly allow workflows that still need the trigger The secure default is not an unconditional removal of `pull_request_target`. Repositories that genuinely depend on it can explicitly allow the event through an Actions event policy, and the new workflow-file targeting means that exception can be limited to specific workflows rather than reopening the trigger broadly. ## Key details - Workflow execution protections are generally available for GitHub Actions at enterprise, organization and repository scope. - Policies evaluate both actor rules and event rules before a workflow runs. - GA adds targeting of individual workflow files. - Insights can show how execution-protection rules would or do affect workflow runs. - A REST API allows execution protections to be managed programmatically. - GitHub is introducing a default public-repository rule disabling `pull_request_target` when no applicable event policy exists. - The default starts in evaluate mode and is scheduled for automatic enforcement for affected repositories on November 2, 2026. ## Builder takeaways - Audit public repositories that use `pull_request_target` now rather than waiting for the November enforcement date. - Use evaluate mode to identify legitimate workflows that a new rule would block before switching enforcement on. - Apply stricter actor/event policies to deployment, release and secret-bearing workflows instead of assuming every workflow in a repository needs the same trust boundary. - If `pull_request_target` is genuinely required, allow it narrowly at the workflow-file level and re-check whether fork-controlled code can reach secrets or privileged steps. - For larger organizations, manage execution protections through the REST API so policy drift can be detected and corrected centrally. ## What to watch - The November 2, 2026 enforcement of GitHub's default `pull_request_target` rule for affected public repositories. - Whether GitHub expands secure defaults to other high-risk Actions events or workflow patterns. - How organizations use Insights to tune actor and event policies before enforcement. - Whether execution-protection APIs become integrated into common GitHub governance and infrastructure-as-code tooling. ## Uncertainties - GitHub's default `pull_request_target` rule applies to affected public repositories rather than every repository; private and internal repositories are excluded from this default. - Repositories can explicitly permit `pull_request_target`, so the change does not eliminate the trigger or the need to review privileged workflow design. ## Sources - [Workflow execution protections in GitHub Actions generally available](https://github.blog/changelog/2026-09-17-workflow-execution-protections-in-github-actions-generally-available/) — GitHub Changelog · primary/vendor · 2026-09-17T00:00:00+12:00. Primary evidence for GA capabilities, workflow targeting, Insights, REST management and the November 2 pull_request_target secure-default enforcement.