GitHub Is Putting a Gate in Front of pull_request_target

pull_request_target is useful because it runs in the context of the base repository. That is also why it is dangerous: the workflow can have secrets or write permissions while responding to code proposed by an untrusted fork.

GitHub’s workflow execution protections are now generally available. Organizations can make allow or block decisions from the actor, event, and target workflow, and can first evaluate rules in a shadow mode that records what would have happened.

This is policy before compute starts

Repository permissions limit what a running job can do. Execution protection decides whether the job should exist at all. That is the right place to reject combinations such as an external actor invoking a privileged workflow through a risky event.

GitHub says public repositories will default to disabling pull_request_target, with enforcement beginning November 2, 2026, unless the event is explicitly allowed. Teams that rely on it should not simply add a blanket exception. They should document why the workflow needs base-repository authority.

Shadow mode is the migration tool

A policy engine without observation usually produces one of two outcomes: it blocks legitimate work on day one, or stays permissive forever. Evaluation mode lets a team compare intended rules with real events before enforcement.

I would collect at least a representative cycle of dependency updates, first-time contributors, bots, release automation, and internal forks. Review each would-block event by workflow file, actor class, and permissions. The output should become a short allowlist tied to a reason, not a growing set of exceptions.

The workflow still needs to be safe

Allowing an event does not make its YAML secure. A pull_request_target job should avoid checking out and executing the contributor’s head revision. Pin third-party actions to immutable commits, minimize token permissions, keep secrets out of unnecessary jobs, and separate analysis of untrusted code from privileged comments or labels.

The REST API makes the controls manageable across organizations, but it also creates a configuration surface that needs review and change history. Policy as code is valuable only when someone owns the policy.

This is a useful platform guardrail because it blocks an unsafe workflow before a runner and token exist. It is not a replacement for reviewing what the permitted workflow does.

Source

GitHub: workflow execution protections are generally available.