GitHub has made workflow execution protections generally available for eligible public and private repositories. The controls let administrators define which actors may trigger workflows, which events are permitted, and which workflow files a policy covers.
The change gives platform teams a policy-based way to restrict automation before it runs. It also adds workflow-file targeting and policy insights, while introducing a default evaluate-mode policy for pull_request_target in affected public repositories. That default policy is scheduled to begin enforcement on November 2, 2026.
What changed in GitHub Actions
Workflow execution protections can be configured at the enterprise, organization, and repository levels. According to GitHub’s administration documentation, the feature is available to repository administrators, organization owners, and enterprise owners. It applies to all public repositories and to private repositories on GitHub Team or GitHub Enterprise. The supplied documentation does not establish broader plan eligibility.
Policies act as allowlists for workflow execution. Administrators can restrict who is allowed to run workflows and which GitHub events may trigger them. Actor rules can distinguish among documented identity types, including selected users, bots, teams, GitHub Apps, enterprise teams, and repository roles. Event rules can cover events such as push, pull_request, pull_request_target, and workflow_dispatch; the REST reference documents a broader supported-event set.
General availability also adds workflow-file targeting. Instead of applying a protection uniformly across an entire repository or account scope, administrators can use workflow-path include and exclude conditions to focus a policy on selected files. This is particularly relevant for sensitive workflows, such as those responsible for deployments or other privileged operations.
Evaluate mode helps teams measure impact
Administrators do not have to begin with active blocking. Evaluate mode allows a policy to observe workflow runs that would be blocked without immediately preventing them from running. Policy insights can show blocked runs for active policies and would-have-been-blocked runs for policies in evaluate mode.
This provides a practical transition path for organizations with existing automation. Teams can review the expected impact, identify legitimate workflow actors and events, and adjust their policies before enforcement. The REST documentation states that evaluate enforcement is available with GitHub Enterprise.
GitHub recommends using multiple clearly defined policies rather than one large policy for an entire account. Policies can be layered across enterprise, organization, and repository levels. However, the supplied documentation does not fully define precedence for every combination of enterprise, organization, repository, actor, event, and workflow-file policy. Administrators should validate their effective behavior using the available policy configuration and insights rather than assuming that every layering scenario behaves identically.
What the default pull_request_target policy means
GitHub has also added a default policy that blocks pull_request_target in affected public repositories that do not already have an applicable Actions event policy. The default initially runs in evaluate mode. For repositories using that default policy before general availability, scheduled enforcement is November 2, 2026.
An existing applicable event policy is not replaced by the default policy. A repository that requires pull_request_target can explicitly allow the event through an applicable policy, or it can leave the restriction in place and change the workflow.
This distinction matters because pull_request_target runs with the base repository’s GITHUB_TOKEN and can access repository and organization secrets. The security risk arises when a privileged workflow checks out, builds, or executes untrusted pull-request code. GitHub’s security guidance describes this pattern as a possible pwn-request vulnerability and recommends avoiding execution of untrusted code in privileged workflows.
The guidance does not state that every use of pull_request_target is unsafe. Where elevated trust is unnecessary, GitHub recommends using pull_request. Where the privileged event is required, teams should use least-privilege token permissions, restrict secrets, use isolated ephemeral runners, and handle checked-out code carefully.
REST API support for policy management
The Actions policies REST reference documents organization policy listing, creation, and update operations. It includes fine-grained token types, required administration permissions, request parameters, policy schemas, examples, response formats, and status codes for the documented operations.
The reference also describes actor and event rule structures, repository targeting conditions, workflow-path include and exclude patterns, and the disabled, active, and evaluate enforcement values. The supplied material includes repository policy operations, but it does not establish complete create, update, and delete endpoint coverage for enterprise-level policies. Teams should use the documented operations rather than assume that equivalent REST coverage exists at every scope.
What administrators should do now
- Identify eligible administrators and repository scope. Confirm whether the relevant account is a public repository or a private repository on GitHub Team or GitHub Enterprise, and identify the repository administrator, organization owner, or enterprise owner who will configure the policy.
- Review evaluate-mode insights. Examine workflows that would be blocked before switching to active enforcement. Pay particular attention to legitimate actors, required events, and workflow files that need exceptions.
- Audit
pull_request_targetworkflows. Public repositories affected by the default policy should review their insights before November 2, 2026. Find workflows that check out or execute code from pull requests and determine whether they require elevated trust. - Prefer safer triggers where appropriate. Use
pull_requestwhen a workflow does not need elevated secrets or token permissions. Ifpull_request_targetis required, explicitly allow it through an applicable event policy and ensure that untrusted code is not executed with privileged access. - Target sensitive workflow files. Use workflow-path conditions when stricter controls are needed for deployment or other privileged workflows without applying the same rule to every workflow in the repository.
- Automate only against documented API operations. Use the REST reference for authentication requirements, administration permissions, schemas, and examples. Do not assume that undocumented enterprise-level operations are available.
Availability and remaining limitations
The protections are generally available after public preview, but the available documentation does not provide a complete migration guide covering every compatibility difference between preview and general availability. It also does not fully document how every existing custom policy interacts with the November 2 rollout beyond the condition concerning an applicable event policy.
For that reason, organizations should treat evaluate mode and policy insights as part of the rollout process. The feature offers centralized controls for workflow execution, but the exact behavior of complex policy combinations should be confirmed in the relevant account configuration before active enforcement.
