Before November 2: check GitHub Actions’ default event-policy impact

A September release with a November decision

GitHub’s September 17 announcement made workflow execution protections generally available and added workflow-file targeting, Insights and a REST management interface. These policies control who may trigger a workflow and which events may start it. Evaluate mode carried over from preview; it was not a new GA feature. [1]

The immediate decision is narrower than adopting the whole policy system. GitHub introduced a default rule blocking pull_request_target for public repositories without an applicable event policy. Its announced November 2, 2026 automatic enforcement applies to affected repositories that were using that default policy before general availability. The detailed security reference repeats that qualification. Do not treat the date as a universal shutdown of pull_request_target. [1][5]

First establish whether this rollout applies

• Check repository visibility. This default does not apply to private or internal repositories; that exclusion is not a statement that their workflows are secure. [1][5]
• Inspect the applicable Actions event policies, not just the workflow’s trigger. The default does not replace an applicable event policy already configured. Policies can exist at repository, organization and enterprise levels. [2][3][5]
• Confirm the rollout history. The November 2 cohort is affected repositories using the default pull_request_target policy before GA. Finding that trigger in a YAML file alone does not establish membership. [1][5]

If you cannot see the effective policies or establish the relevant history, leave applicability unconfirmed and ask the responsible administrator to resolve it. Do not turn missing visibility into either an exemption or a reason to enable the event broadly. That is a decision rule for handling the evidence gap, not a claim about your repository.

Read the impact before changing a policy

For a repository or organization, open Settings → Actions → Policies. Policy insights sits directly below the policies page in the sidebar. At enterprise level, the route is Policies → Actions → Policies, with Policy insights beneath it. These controls are separate from Actions’ General settings. [2][3]

• Identify the relevant default event policy and its actual enforcement mode. GitHub’s captured rollout documentation describes the default as running in evaluate mode: workflows continue, while Insights identifies runs that would be blocked after enforcement. [5]
• Separate “would be blocked” evaluation results from runs already blocked by active policies. Policy insights can show both; they answer different questions. [3]
• For each affected workflow file, identify the operational task that would stop and why it needs pull_request_target. Review the event requirement, rather than assuming every affected run needs an exception. [1][5]
• Record the decision with the exact workflow path, the effective policy scope, the reason for retaining or allowing the event, and any unresolved evidence. After an authorized change, verify actual behavior rather than treating the intended setting as the result. This is a recommended review record, not a report of tests performed here.

Do not confuse the default’s rollout mode with entitlement to create a custom evaluate-mode policy. The current how-to labels selecting Evaluate “GitHub Enterprise Cloud only”; the REST reference also restricts evaluate to GitHub Enterprise. That does not make other public repositories exempt from the documented default rollout. Verify the options and permissions available in your actual account; this article has not inspected them. [3][4][5]

Retain the block unless a workflow needs an allowance

Workflow-file targeting makes a narrower decision possible; it does not make the workflow safe. Protections layer across repository, organization and enterprise scopes. If actor and event restrictions both apply, an allowed actor still needs an allowed event. Inspect the full effective policy set before assuming a repository-level allowance will permit a run. [1][3]

If managing policies through the REST API, do not mistake an omitted workflow condition for a narrow target. The reference says omitting workflow_path on creation targets all workflows; omitting it on update preserves existing targeting. Inspect the target explicitly rather than copying an untested write payload. No API operation is required to use this briefing. [4]

Hypothetical example: keep testing blocked, review labeling separately

Hypothetical example—NOT RUN. Assume a public project’s administrator has confirmed membership in the stated pre-GA default-policy cohort and has inspected inherited policies. Its evaluation results show two affected files: .github/workflows/test-pr.yml, which fetches fork code and runs tests with privileged access, and .github/workflows/label-pr.yml, intended only to apply labels from pull-request metadata. These are invented example paths and assumptions, not observations of a real project.

• Testing decision: retain the pull_request_target block for test-pr.yml. Investigate moving untrusted testing to an appropriate lower-trust design, such as pull_request where suitable; do not allow privileged fork-code execution merely to avoid a blocked run. The redesign and its verification remain work to do. [5]
• Labeling decision: if review confirms that label-pr.yml genuinely needs the privileged event, treats untrusted input as data, and uses only necessary token permissions and secrets, consider an applicable event allowance targeted only to .github/workflows/label-pr.yml. Check the effective inherited and actor restrictions before expecting it to run. The label-only description is not itself security evidence. [1][3][5]

The completed decision is not “enable pull_request_target for the repository.” It is “keep the testing path blocked; consider a separate, narrowly scoped labeling allowance only after its conditions are established.” No successful run, secure implementation or override of inherited policy is claimed by this example.

An execution allowance is not a security verdict

pull_request_target uses the base repository’s privileged context, with its GITHUB_TOKEN and access to secrets. GitHub explains that checking out fork code is not, by itself, execution. The dangerous crossing occurs when a later step runs the fetched Makefile, test command, dependency or configuration with that privileged access. Review what actually executes, not just the event name or checkout step. [5]

Moving the same untrusted execution into workflow_run or issue_comment does not remove this risk. GitHub documents the same vulnerable pattern for other events running with secrets. A necessary allowance therefore still needs least-privilege token and secret handling and a separate review of untrusted input and execution. This briefing is about event-policy rollout, not a claim that this one control prevents every workflow compromise. [5]

What to settle before enforcement

For a confirmed affected repository, finish with a named outcome for each impacted workflow: retain the block, redesign an unnecessary privileged trigger, or consider a justified file-scoped allowance. Keep the operational consequence and unresolved conditions beside that outcome. If applicability is unconfirmed, resolve the policy/history gap first instead of using November 2 as a blanket instruction to change settings.

The evidence here is GitHub’s announcement and documentation checked on October 16, not an account audit or a CI migration test. Documentation-page publication and update dates were not established; September 17 is the announcement date. Recheck current guidance and your effective settings before acting. A changed rollout notice, a different applicable policy or missing evidence of necessity should change the decision—not be edited out to preserve an allowance.