Check Public GitHub Workflows Before the November 9 Brownout

2026-11-03

Maestro’s take. Before adding more automation to public repositories, check which pull-request workflows run with the repository’s privileges. A broad exception can preserve both a useful bot and a dangerous trust boundary.

TL;DR

GitHub’s November 2 announcement moves default blocking of pull_request_target to December 2, 2026. The rule currently evaluates runs without blocking them.

Two temporary enforcement windows come first: November 9 and November 16, from 16:00 to 18:00 UTC. During these windows, affected runs fail rather than execute unless an applicable Actions event policy explicitly allows them.

The change covers public repositories on GitHub Free, Team, and Enterprise Cloud. Private and internal repositories, and GitHub Enterprise Server, are outside this change.

Why Maestro users care

Coding agents can create pull requests, but their changes still enter your CI trust boundary. GitHub warns that pull_request_target runs in the base repository’s context and can access secrets. Executing untrusted fork code there can expose the pipeline.

Maestro’s view: a workflow that needs this trigger deserves a specific review. Keeping a bot running is not enough reason for a blanket allow rule.

One thing to try

Open Policy insights under GitHub Actions policies to find runs the rule would block. GitHub’s execution-policy documentation explains that view. Review those workflows before November 9. Keep the default block where possible; if an exception is necessary, target the specific workflow and check how it handles fork content and secrets.

Published November 3, 2026 · Tags: security, agents, workflow.