GitHub Turns Off pull_request_target Nov 2: Check AI Bots

On September 17, 2026 GitHub made workflow execution protections generally available and, in the same changelog, announced a new default: public repositories will no longer run workflows started by the pull_request_target event. The rule is live now in evaluate mode, which logs what it would block without blocking it. GitHub says it will enforce the rule on November 2, 2026 for public repositories that were on the default policy before the release.

The trigger matters to anyone who installed an AI code-review or triage bot as a GitHub Actions workflow. Those bots often use pull_request_target because it is the event that lets a workflow comment on a pull request from a fork while holding a token that can write. This post explains what the trigger does, who is affected, why AI bots are the workflows most worth checking, and what GitHub's changelog and its reference page on using the trigger safely say to do before the date.

GitHub Actions has two events for pull requests. The ordinary pull_request event runs the workflow from the pull request's own merge commit. When the pull request comes from a fork, that code was written by someone without write access, so GitHub runs it with a read-only token and no secrets. The workflow can test the change but cannot post a comment, add a label or reach a private service.

pull_request_target flips one thing. The workflow file, and any checkout that does not name a ref, come from the base repository's default branch instead of the pull request. Because only trusted code runs, GitHub grants the job the base repository's token and its secrets. GitHub's documentation describes this as the same trust given to a push event, which only collaborators can trigger. The intended uses are labelling, triage and posting authenticated status checks on pull requests from forks.

The risk appears when a workflow author overrides that default and checks out the pull request's head commit, then runs anything from it: a build script, a test command, a dependency install. The workflow file is still trusted, but the Makefile it just executed was written by whoever opened the pull request. GitHub's Security Lab named this pattern a "pwn request" in its guidance for maintainers, and GitHub's changelog calls vulnerabilities in these workflows "one of the most commonly exploited vulnerabilities in action workflows". The documentation adds that the pattern has been the root cause of multiple supply-chain compromises, without naming them.

The default rule is narrow. It is an event policy, one of the two rule types in execution protections: actor rules decide who may start a workflow, event rules decide which events may start it. The table below is our reading of the conditions GitHub states in the changelog and the reference page. An "applicable event policy" is one that already covers the repository at the repository, organisation or enterprise level.

One more scope note. GitHub's how-to page says execution protections are available on all public repositories and on private repositories on the Team and Enterprise plans, and that evaluate mode for your policies you create yourself is an Enterprise Cloud feature. The changelog says the default rule itself runs in evaluate mode and that its results appear in insights; it does not tie that to a plan, so check your own repository's insights page rather than assuming either way.

An AI code-review bot installed as a workflow does three things: it reads the pull request, it calls a model, and it posts a comment. The comment needs a token that can write to pull requests. On a pull request from a fork, the ordinary event will not provide one, so many such workflows are written on pull_request_target. That is a legitimate use in GitHub's own terms, as long as the workflow never runs the pull request's code.

The difference from a labeller is what the bot consumes. A labeller reads a file path. A review bot reads the title, the description and the whole diff, all written by the person who opened the pull request, and passes them to a model that then decides what to do. If the model can call tools, or its output feeds a later step, the pull request text is an instruction channel into a job that holds the repository's secrets. This is prompt injection with a write token attached. GitHub's reference page does not discuss AI bots specifically; it says any step that executes content from the pull request completes the vulnerability, and that the checkout step alone does not. A model acting on untrusted text is the same structure with a different executor.

The second exposure is more mundane. Some review bots check out the pull request head so they can run linters or tests before commenting. That is exactly the insecure example on GitHub's page. GitHub has also changed actions/checkout so that checking out a fork's pull request ref now requires an input named allow-unsafe-pr-checkout: true, chosen, the page says, so that reviewers and static analysis can spot it. If that string appears in a bot's workflow, the bot is running untrusted code with secrets.

The changelog offers two paths for an affected workflow. The reference page adds a third that comes first: change the workflow to a safer event if it does not really need the privileged one. Workflow file targeting, new at general availability, makes the allow path precise. A policy can permit pull_request_target for review-bot.yml alone and leave every other workflow under the block.

Option C is the one GitHub's Security Lab designed the workflow_run event for. The unprivileged job builds or reviews, writes its result to an artifact, and a second privileged job downloads that artifact into a temporary directory and comments. The example's own comment warns not to extract the artifact into the workspace, because the workspace may contain executable scripts. For an AI bot the "result" is the review text, which the second job posts without ever having held the model's tools and the secrets at the same time. A bot installed as a GitHub App rather than a workflow sidesteps the question, because it authenticates as the app and not through a repository token.

The audit is short because GitHub has done the discovery. Five steps, in order.

1. List the workflows on the trigger. Search every public repository's .github/workflows directory for pull_request_target. Then open the policy insights page, which lists the runs the default rule would have blocked since it went live.
2. Sort each hit into three piles. Comment-only bots and labellers that never check out code; workflows that check out or fetch pull request code; workflows that need the trigger for an authenticated check. Only the first and third are candidates for an allow policy.
3. Grep for the unsafe inputs. allow-unsafe-pr-checkout, ref: ${{ github.event.pull_request.head.sha }}, repository: ${{ github.event.pull_request.head.repo.full_name }}, and any gh pr checkout or git fetch of a pull request ref. Each is a listed vulnerable shape.
4. Move AI bots that run tools to the two-workflow shape or to a GitHub App. For a bot that only comments, keep it on the trigger only if its model output never feeds a shell step, and set the token's permissions to pull-requests: write and nothing more. Our earlier post on credentials for non-human actors covers the scoping rules.
5. Write the allow policy last, and narrowly. Use workflow file targeting so the exception names files. Re-check insights a week after enforcement to confirm nothing else was relying on the trigger.

Two related notes. Workflows on the trigger have read-only access to the Actions cache in the default branch's scope, so a cache save from one of these jobs fails while the job continues; GitHub documents this as a cache-poisoning defence. And if the bot runs on a self-hosted runner, GitHub's page says the runner must be isolated and not reused across runs. That is the same lesson as the agent sandbox escapes we catalogued: the executor's boundary matters more than the instructions. For the wider pipeline shape, our CI/CD design reference and the AsyncAPI supply-chain post show what a compromised job can reach. If you want a second pair of eyes on an agent pipeline's permissions, our AI transformation service includes that review.