GitHub Actions adds execution protections and a default pull_request_target block

GitHub has made workflow execution protections for GitHub Actions generally available, giving enterprises, organizations, and individual repositories a built in way to control who can start a workflow and which events are allowed to trigger it. The change matters most for teams that run automation from public repositories, where a convenient workflow trigger can also become a supply chain risk.

The new controls separate actor rules from event rules. In plain terms, administrators can define who is allowed to run a workflow and what kind of GitHub event is allowed to start it. GitHub says Actions checks both sides before a run proceeds. General availability also adds workflow file targeting, so a repository can apply tighter rules to a sensitive deployment workflow while leaving routine continuous integration jobs open to normal contributors.

What changes for administrators

GitHub also added insights and a REST API for these protections. The insights view is intended to show how rules are evaluated and enforced across an enterprise, organization, or repository. The API allows teams to create, read, update, and delete rules programmatically, including conditions tied to workflow paths. That makes the feature more useful for large software organizations because Actions policy can be managed as code instead of being maintained only through settings screens.

The most concrete security change is a new default protection for public repositories that do not already have an applicable event policy. GitHub says it is introducing a default rule that disables the pull_request_target event. The company is starting the rule in evaluate mode, which lets maintainers see which runs would be affected before enforcement starts.

Why pull_request_target gets special treatment

The pull_request_target trigger is powerful because it runs in the context of the base repository and can access secrets. That is useful for some workflows, but it becomes dangerous when untrusted code from a fork is executed inside that privileged context. GitHub specifically points to Pwn Requests as an example of the class of vulnerability it is trying to reduce.

On November 2, 2026, GitHub says it will automatically enforce the default rule for affected public repositories that were still using the default pull_request_target policy before general availability. Private and internal repositories are not covered by that default.

The practical decision for maintainers is not simply to turn everything back on. Teams should use the evaluate period to identify workflows that depend on pull_request_target, then decide whether each one genuinely needs that trigger. Sensitive deployment, release, and secret using workflows deserve the narrowest policy. If a workflow still needs the trigger, GitHub says specific workflow files can be allowed through the new targeting controls.

Sources

• github.blog

Cover photo by Antoni Shkraba on Pexels, used under the Pexels License.