What happened
GitHub’s changelog says the new default applies to all public repositories on GitHub Free, GitHub Team, and GitHub Enterprise Cloud. It does not apply to private or internal repositories, or to GitHub Enterprise Server. GitHub had previously scheduled enforcement for November 2, 2026, and says it has moved the date to December 2.
The rule comes through GitHub Actions workflow execution protections. It initially runs in evaluate mode, so repository teams can see which workflow runs the rule would block before enforcement begins. GitHub schedules two temporary enforcement windows ahead of the permanent change: November 9 and November 16, 2026, each from 16:00 to 18:00 UTC. During those windows, attempts blocked by the default rule in affected public repositories will create failed runs with an error annotation; the workflows will not execute. After each window, the rule returns to evaluate mode, allowing workflows to run with warnings.
GitHub’s stated security rationale is about the context in which pull_request_target runs. The event executes in the context of the base repository and can access its secrets. If a workflow executes untrusted code from a fork, that code could compromise the pipeline or steal secrets. The default block is intended to reduce that risk while leaving a route for workflows that genuinely depend on the trigger.
To prepare, GitHub directs users to Insights to find workflow runs that the rule would block, and recommends doing so before the first brownout on November 9. Teams can keep the default block or explicitly allow pull_request_target in an applicable Actions event policy. GitHub also describes workflow-file targeting as a way to allow specific workflows. Its changelog points to guidance on controlling workflow execution, but does not state that all affected workflows will be identified or remediated automatically.
What the archive adds
New Runtime’s earlier coverage on November 14 described Agentic Workflows v1.2.0 requiring opt-in before pull_request_target workflows run on forks (Agentic Workflows v1.2.0 requires opt-in before pull_request_target runs on forks). That was a tool-specific safeguard; GitHub’s announcement is a platform policy change for public repositories. This is a new fact on a known security thread, not a restatement.
Trend signal
This does not yet fit a pattern New Runtime tracks. GitHub’s default is a concrete execution-policy change, but the announcement alone does not establish a broader shift in how AI-agent security boundaries are designed or deployed.
Why now
GitHub says permanent enforcement begins December 2, 2026, after two scheduled brownouts on November 9 and 16. The temporary windows give teams a chance to see actual failed runs, while evaluate mode between them allows workflows to continue with warnings. The schedule makes inspection before the first brownout the immediate operational step.
Connections to other events
The announcement intersects with GitHub’s earlier Agentic Workflows change: New Runtime’s November 14 note says version 1.2.0 added an opt-in requirement before pull_request_target workflows run on forks (Agentic Workflows v1.2.0 requires opt-in before pull_request_target runs on forks). Both address the risks around running fork-triggered workflows, but the GitHub changelog describes a default for public repositories across the platform rather than a versioned safeguard in one tool.
Why it matters
A default block can reduce exposure to a class of workflow risks without requiring every repository owner to discover the issue first. But it can also interrupt legitimate automation: a team that depends on pull_request_target may see its workflow stop during enforcement unless an applicable policy permits it. The consequences are therefore both security-related and operational—missed checks or automation failures can affect pull-request handling.
The practical dividing line is whether a workflow actually needs this trigger and, if so, whether its exception can be limited to the specific workflow that needs it. Teams should review the runs flagged in Insights, understand why each workflow uses the event, and test any policy change. A broad allow rule may preserve existing behavior, but it also gives up some of the protection GitHub is introducing. The announcement describes the available controls, not a universal migration path for every workflow.
What happens next
- Affected public repositories will need an explicit policy exception to keep dependent
pull_request_targetworkflows running after enforcement. (3 months, 85%). Watch for: failed workflow runs or policy guidance from GitHub after December 2.
Limits and uncertainty
GitHub’s changelog does not quantify how many public repositories or workflows the rule will affect, or how often those workflows depend on pull_request_target. It does not report measured reductions in compromised pipelines or stolen secrets. The announcement also does not describe an automatic remediation process; repository teams are directed to inspect Insights and choose whether to allow the trigger. The stated schedule and scope come from GitHub, and the security rationale is not an independent measurement of the rule’s impact.
Skill to build now
Before the first brownout, use GitHub Actions Insights to identify runs that the default rule would block. For each affected workflow, record why it uses pull_request_target and whether it handles fork code or repository secrets. If the workflow must continue, use an applicable event policy and target only the necessary workflow files where possible; then verify the result during the scheduled enforcement windows.
Reader takeaway
For public GitHub repositories, pull_request_target is becoming opt-in at the policy level. Check Insights before the November brownouts, decide which workflows truly need the trigger, and make any exception as narrow as the workflow allows.