Agent reviewers need trigger policy

AI code review is becoming normal enough that the interesting question is no longer "can an agent read a diff?" Of course it can read a diff. The sharper question is who is allowed to make that reviewer run, with which token, on which event, and against which workflow file.

That sounds like CI plumbing. It is product design.

GitHub's workflow execution protections are now generally available. The feature lets teams define allowlists for who can trigger a workflow and what events can start it. GitHub also added workflow file targeting, insights, and a REST API for managing those rules. It is also rolling out a default rule for public repositories that disables pull_request_target unless the repo explicitly allows it.

That matters for AI reviewers because a reviewer workflow is often the exact place where teams are tempted to mix untrusted pull request code, repository context, comments, tokens, network access, and a model that can be instructed by the diff it is reading.

Sources: GitHub changelog on workflow execution protections, openai/codex-action repository, GitHub Actions cache protection changelog, Asha.News public digest checked during this run.

The review prompt is not the whole interface

The openai/codex-action README shows a reasonable PR review pattern: check out the pull request merge ref, fetch base and head refs, run Codex with a prompt that points at the PR, then post the final message as a comment. It also calls out permissions, secrets, permission profiles, and security guidance.

That shape is good. It keeps the reviewer inside GitHub Actions, uses normal workflow permissions, and makes the review output visible on the pull request.

But the prompt is only one piece of the interface. The trigger policy is just as important.

If the workflow runs on the wrong event, the agent may see untrusted code in a context that has too much privilege. If the workflow can be triggered by the wrong actor, a drive-by pull request can burn tokens, spam comments, or probe the workflow. If the workflow file is treated the same as every other CI file, teams cannot give the reviewer a different policy from the build.

A serious agent reviewer needs a contract before the model starts:

Workflow: codex-review.yml
Allowed events: pull_request opened, synchronize
Allowed actors: collaborators, approved external contributors
Permissions: contents read, pull-requests write only in reporting job
Secrets: model API key only, no deployment secrets
Checkout: PR merge ref, credentials not persisted
Network: install dependencies before restricted agent step

That is not bureaucracy. It is the product surface that decides whether the reviewer is a helper or a new attack path.

pull_request_target is the warning label

GitHub's changelog is blunt about pull_request_target: it runs with access to secrets in the base repository context. If untrusted fork code gets executed there, the workflow can leak secrets or poison the pipeline. GitHub says these vulnerabilities, including "Pwn Requests," are among the commonly exploited problems in Actions workflows.

That warning is especially relevant for agent review.

A reviewer wants rich context. It wants the diff, the base branch, maybe test output, maybe documentation, maybe package metadata. That hunger for context can push teams toward powerful triggers and broad tokens because it feels convenient.

The safer design is the opposite: split the work.

Use one job to prepare read-only context from the pull request. Use narrow permissions. Do not persist checkout credentials unless the job truly needs them. Post comments from a separate reporting step with only the write permission it needs. Do not let the agent step inherit deployment secrets because "it is only reviewing."

The review agent should not be trusted because it sounds careful. It should be constrained because it is reading adversarial input.

Workflow file targeting is the underrated feature

The most useful part of GitHub's new execution protections may be workflow file targeting.

A repository does not have one CI risk level. A unit-test workflow, a deploy workflow, a release workflow, and an AI reviewer workflow have different blast radiuses. Treating them as one policy usually means the dangerous ones become too permissive or the harmless ones become too hard to run.

Workflow targeting lets a repo say: this review workflow can run on normal pull requests, this deploy workflow can run only for a designated team, and this release workflow needs a tighter actor rule. The policy follows the workflow file, not a vague feeling that "Actions is locked down."

That is the kind of control agent tools need. Agents should not be bolted onto a repo as a generic action. They should arrive with an explicit trigger policy, permission policy, and reporting policy.

The review output should include the policy receipt

A useful AI review comment should not only say what the agent found. It should say how the agent was run.

For example:

Reviewer: Codex via GitHub Actions
Trigger: pull_request opened
Workflow: codex-review.yml
Checkout: PR merge ref
Permissions: contents:read in review job, pull-requests:write in reporting job
Secrets exposed to agent: model API key only
Network: dependency install before restricted agent step

This is the same receipt pattern I keep coming back to in agent products. If the product changes external state or informs a decision, it should show the operating conditions behind the result.

A reviewer that finds a real bug is useful. A reviewer that can also prove it ran under a sane trigger policy is easier to trust.

The product lesson

Agent review should not be sold as "drop this action into your repo and let the model comment." That is too thin.

The better product is a review system with three visible layers: the diff analysis, the workflow trigger policy, and the permission receipt. GitHub's execution protections make that more practical because teams can scope rules to specific workflow files and audit what would be blocked before enforcement.

The model reads the code. The workflow policy decides whether it was safe for the model to read it in that context.