GitHub Actions can now block who or what starts a workflow — and `pull_request_target` is getting a secure default

GitHub Actions workflow execution protections are now generally available for enterprises, organizations and repositories. Policies can allow or block workflow execution based on the actor and triggering event, and GA adds rules scoped to individual workflow files, an Insights surface for observing policy decisions and REST endpoints for managing the protections as code. GitHub is also introducing a default event policy for public repositories that disables `pull_request_target` when no applicable event policy already exists. The rule begins in evaluate mode and, for affected repositories using the default policy, is scheduled to become enforced automatically on November 2, 2026.

GitHub is moving an important CI security boundary from workflow-by-workflow convention into a platform policy layer that runs before a workflow starts. `pull_request_target` is particularly risky because it executes in the base repository context and can have access to secrets even when the change originates from a fork. Teams can now shadow-test rules, target especially sensitive workflows such as deployments, and manage policy across repository fleets rather than relying only on YAML review and contributor discipline.

Actor rules control who may start a workflow and event rules control which triggers may start it. GitHub evaluates both before execution. That makes the policy independent of logic inside the workflow file and gives organizations a separate enforcement boundary for sensitive automation.

Rules can now target particular workflow files, so a repository can apply stricter controls to a deployment or release workflow without imposing the same restrictions on ordinary CI. GitHub also exposes Insights for seeing how rules evaluate runs and REST endpoints for creating, reading, updating and deleting protections at enterprise, organization and repository scope.

For public repositories without an applicable event policy, GitHub is rolling out a default rule that disables `pull_request_target`. It starts in evaluate mode so maintainers can inspect the workflows that would be affected. On November 2, 2026, GitHub says it will automatically enforce the default for affected repositories that were using the default `pull_request_target` policy before GA.

The secure default is not an unconditional removal of `pull_request_target`. Repositories that genuinely depend on it can explicitly allow the event through an Actions event policy, and the new workflow-file targeting means that exception can be limited to specific workflows rather than reopening the trigger broadly.