GitHub Actions workflow execution protections reach general availability, and public repos get a pull_request_target default that enforces on November 2

GitHub moved workflow execution protections in GitHub Actions from public preview to general availability on 17 September 2026. The same announcement adds a default protection to public repositories that disables pull_request_target for workflows that do not already have an event policy attached, and turns that default into enforcement on 2 November 2026.

What the protections do

Execution protections evaluate two rules before a workflow starts running: an actor rule about who can trigger the workflow and an event rule about which events can start it. Administrators define an allowlist for each, and a workflow that fails either rule is refused before it runs. GitHub describes the target in its own words as "if code is executed from a fork, that untrusted code could poison your pipeline and exfiltrate secrets," which is what pull_request_target has always let a maintainer opt into.

Because the trigger runs with the base repository's context and its secrets, pull_request_target on a public repository has been the most common way maintainers ship a workflow that a fork can turn against them. The protection layer now filters those runs by policy before they start.

What is new at general availability

Three pieces landed with the general availability flag. Policies can now target individual workflow files, so a repository can be strict about one workflow and open on the rest. There is an insights dashboard that reports how policies have affected runs across an enterprise, organisation or repository, and a REST API for reading and writing the policy set. The feature is available for GitHub Enterprise, organisations and repositories.

The new default, and its enforcement date

For public repositories, GitHub is adding a protection that disables pull_request_target for any workflow that does not already have an event policy set on it. It runs in evaluate mode first, which reports what would have been blocked without blocking anything, and switches to enforcement on 2 November 2026. The changelog names that specific date.

Two things follow from the date. A workflow that legitimately needs pull_request_target on a public repository, such as one that comments on a fork's pull request or labels it, has to be named in an event policy that allows the trigger before enforcement day, or the workflow will stop running. And evaluate mode is the six weeks a repository owner has to look at the insights dashboard and see which workflows would have been refused, so an unexpected block on 2 November is a workflow that nobody checked.

Private repositories are not covered by this default. An administrator can still set the same policy by hand on any repository.

Two operational notes. The changelog announces general availability, so any breaking behaviour is on by default now, and the six weeks between announcement and enforcement is a genuine grace period that expires. And a policy that fires an unwanted block does so silently until someone reads the dashboard, so a public repository with a busy fork community should treat the evaluate window as a review deadline.

Source

GitHub, "Workflow execution protections in GitHub Actions generally available", The GitHub Blog changelog, 17 September 2026.