Workflow execution protections in GitHub Actions generally available

Workflow execution protections for GitHub Actions, previously in public preview, are now generally available for GitHub Enterprise, organizations, and repositories.

Execution protections let you define an allowlist that controls who can trigger an Actions workflow and what events can start it. Actor rules cover the who, event rules cover the what, and actions evaluate both before a run.

What’s new

Alongside the actor and event rules you’ve used in public preview, general availability adds:

• Workflow file targeting: Scope execution protection rules to specific workflow files rather than an entire repository, so a single repository can apply different policies to different workflows. For example, restrict deploy.yml to a designated team while leaving CI workflows open to all contributors.
• Insights: See how actions evaluate and enforce your rules across your enterprise, organization, and repositories. This enables you to audit policy impact and tune rules both before and after you enforce them.
• REST API: Manage execution protections programmatically at the enterprise, organization, and repository level. Create, read, update, and delete rules — including workflow path conditions — so you can manage Actions policy as code, keep rules consistent across hundreds of repositories, and wire enforcement into your existing governance tooling instead of clicking through settings.

Evaluate mode also carries over from the preview, so you can run rules in shadow mode and see which workflow runs would be blocked before you enforce them.

New secure defaults

Vulnerabilities in pull_request_target workflows, such as Pwn Requests, are one of the most commonly exploited vulnerabilities in action workflows. pull_request_target runs with access to your secrets in the context of the base repository, so if code is executed from a fork, that untrusted code could poison your pipeline and exfiltrate secrets. We’re rolling out a default protection rule to limit the execution of pull_request_target events.

For public repositories that do not already have an applicable event policy, GitHub is introducing a default rule that disables pull_request_target. This default does not apply to private or internal repositories. It initially runs in evaluate mode, so you can see which workflow runs would be affected before enforcement begins.

On November 2, 2026, we’ll automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before general availability.

To prepare for the roll out of this rule, you can view the results of the evaluate rule using Insights and see which workflow runs will fail once enforcement begins.

From there you have two options: leave the rule in place to block pull_request_target, or explicitly allow pull_request_target in an applicable Actions event policy if your workflows still depend on the trigger. Specific workflows can be allow-listed using the new workflow file targeting.

To get started, see About Actions policies, Control workflow execution, and the Actions policies REST API reference.

The post Workflow execution protections in GitHub Actions generally available appeared first on The GitHub Blog.