A deployment workflow can reach secrets, packages and production systems. Deciding who can start it is an access-control decision, even when the trigger is a line in a YAML file.
GitHub made workflow execution protections generally available on 17 September 2026. Rules can control the actors and events that start workflows, with targeting for individual workflow files.
There is a default-policy deadline to check
GitHub is introducing a default rule disabling pull_request_target for public repositories without an applicable event policy. The rule initially evaluates the effect without blocking runs.
The announcement gives 2 November 2026 as the automatic enforcement date for affected repositories that were using the default policy before general availability. Private and internal repositories are outside this particular default rollout.
Check your repository's actual policy and evaluation results. An organisation-wide assumption that every workflow is affected, or none is affected, will miss the details.
Start with workflows that can change production
List workflows that deploy, publish packages, change infrastructure or use sensitive credentials. Record how each starts and who should be allowed to trigger it.
A basic test workflow and a production deployment may live in the same repository but need different rules. Workflow-file targeting makes that distinction easier to express.
Include automated actors in the review. Release bots and scheduled tasks need a deliberate place in the policy, with permissions appropriate to their work.
Review what the workflow executes
The pull_request_target event deserves care because it runs in the base repository context and can access secrets. Executing code taken from an untrusted fork in that context can expose the pipeline.
For each affected workflow, identify which code it checks out, which scripts it runs and which inputs influence commands. Ask whether the task requires that privileged context in the first place.
Take particular care with workflows that started as simple labelling or commenting jobs and later gained extra steps. A small addition can change what the job is capable of doing.
Use evaluation results before enforcing
The available evaluation mode and insights can show which real runs a proposed rule would affect. Use that evidence to check normal contributor activity, bot releases and your incident deployment route.
If a legitimate workflow needs an exception, make the exception specific and document the reason. Broadly allowing a risky trigger because one job depends on it weakens the rest of the policy.
Plan a supervised test with the people who maintain the affected workflows. They should know how a blocked run will appear and who can resolve it.
Before November, aim to have a short, reviewed list of privileged workflows, their permitted triggers and any justified exceptions. That is a useful improvement to the release process whether or not the default rollout applies to your repository.
Reporting checked on 13 October 2026. Enforcement dates and repository scope follow GitHub's announcement.
