Actions protections leave preview

GitHub announced on September 17 that workflow execution protections for GitHub Actions have moved from public preview to general availability. The feature is available for GitHub Enterprise, organizations and repositories, giving administrators a way to define an allowlist for workflow execution.

The protections evaluate both the actor attempting to start a workflow and the event that would trigger it. Actor rules determine who is permitted to initiate a run, while event rules determine which types of events may start one. GitHub Actions evaluates both categories before a workflow run begins.

Policies can target individual workflows

General availability adds workflow file targeting, allowing an execution protection policy to apply to specific workflow files instead of an entire repository. This enables different workflows in the same repository to operate under different rules.

GitHub gives deployment as an example: an organization could restrict deploy.yml to a designated team while leaving continuous integration workflows available to all contributors. The file-level option is also intended to support more precise control as teams decide which workflows need additional restrictions.

Insights and API support governance

The release also adds Insights for reviewing how Actions evaluates and enforces execution protection rules across an enterprise, organization and repositories. GitHub says the information can help teams audit the effect of policies and adjust them before or after enforcement.

A REST API provides programmatic control at the enterprise, organization and repository levels. Administrators can create, read, update and delete rules, including conditions based on workflow paths. That allows teams to manage Actions policies as code, keep settings consistent across many repositories and connect enforcement to existing governance tools.

Evaluate mode remains available

The generally available feature retains evaluate mode from the public preview. In this mode, organizations can run rules in shadow mode and inspect which workflow runs would be blocked without immediately preventing those runs.

GitHub positions the mode as a way to assess policy impact before enforcement. Teams can use the resulting information to identify workflows that depend on a restricted actor or event, then adjust their policies or workflow configuration before a rule becomes active.

Default protection targets pull_request_target

GitHub is also rolling out a default protection rule for pull_request_target events. The company describes vulnerabilities in pull_request_target workflows, including Pwn Requests, as among the most commonly exploited vulnerabilities in Actions workflows.

The trigger runs with access to secrets in the context of the base repository. GitHub warns that when code from a fork is executed, untrusted code could poison the pipeline and exfiltrate secrets. For public repositories without an applicable event policy, the new default disables pull_request_target. The default does not apply to private or internal repositories.

Enforcement begins in November

The new default rule initially runs in evaluate mode, allowing affected repositories to use Insights to see which workflow runs would be affected. GitHub says this will show teams which runs are expected to fail once enforcement starts.

On November 2, 2026, GitHub plans to automatically enforce the default rule for affected repositories that were using the default pull_request_target policy before general availability. Teams can leave the rule in place to block the trigger, or explicitly allow pull_request_target through an applicable Actions event policy if their workflows still require it. Specific workflows can be allow-listed with workflow file targeting.

Sources

• GitHub ChangelogWorkflow execution protections in GitHub Actions generally available