A green build can be the wrong repair

A contributor opens a pull request. Its tests cannot access a publishing credential, so a coding agent proposes changing the workflow trigger and increasing token permissions. The new plan may make the error disappear while giving unreviewed code authority it never needed.

The first question is not how to expose the missing secret. It is whether the task needs that secret at all. Testing a proposed change, commenting on its result and publishing a release are different operations.

This guide is for maintainers reviewing agent-generated GitHub Actions changes. It proposes a review method, not a ready-to-run workflow or a finding that your repository is vulnerable.

Methodology: draw the execution and authority map

We reviewed GitHub's event reference, secure-use guidance and token-permission documentation on October 1, 2026. No pull request code was executed, no production token was inspected and no security certification was performed.

Our selection criteria are the workflow's source, the code that will execute, the credentials available to that code, and the external action the job can perform. A YAML diff alone may hide the relationship between those four facts.

This differs from our version-bound review guide, which concerns evidence attached to a Skill package. Here the object under review is the CI execution boundary.

Identify what the trigger actually permits

GitHub's event documentation distinguishes pull_request from pull_request_target. The latter uses the default-branch context of the base repository and can support operations such as labeling or commenting. GitHub advises against using it when the purpose is to build or run pull request code.

For a proposed change, ask the agent to identify the effective event, workflow revision, checkout revision and commands. Do not accept a description such as trusted workflow without knowing which files the trusted workflow will subsequently execute.

Consider a hypothetical test job that checks out a contributor's revision and runs its package installation and tests. Treat both steps as execution of material influenced by that contribution. Renaming the job to review does not change that boundary.

Keep the test separate from the privileged action

GitHub's secure-use guidance warns about untrusted code checkout in privileged pull_request_target or workflow_run workflows, including risks involving secrets, repository writes and caches.

Our proposed design separates a limited test context from any privileged follow-up. The test should produce evidence, not perform publication. A follow-up should perform only a narrowly defined operation using trusted logic.

Separation is not achieved merely by moving code into another YAML file. A privileged follow-up that runs an uploaded script has reintroduced the same problem. Treat artifacts and result text from the test as untrusted data.

For example, a comment publisher might need a validated result summary and a confirmed pull request identity. It does not need to execute an arbitrary helper supplied by the pull request. Define accepted fields and destinations before building that bridge.

Grant the permission required by the action

The GITHUB_TOKEN documentation describes permission controls at workflow and job level and recommends least-required access.

Translate that into a task-specific permission budget. The test job's budget, comment job's budget and release job's budget should be explained separately. If a proposed repair broadens access, the agent should name the exact action that requires it.

Review other credentials too. Narrowing GITHUB_TOKEN is not evidence that every referenced secret, service account or network resource has an appropriate scope. Do not print secret values to demonstrate that they exist.

If the workflow can only be made to pass by giving unknown code publishing authority, return a design problem for review instead of treating permission expansion as routine maintenance.

Review one proposed change with a concrete checklist

Use a non-production fixture repository without valuable secrets for any behavioral exercise. Before running it, write the expected boundaries:

Contributor-controlled code can run only in the intended limited context.
A result cannot choose an arbitrary repository, branch or publication destination.
A privileged step does not execute a contributor-controlled artifact.
A changed revision requires the intended review again.
Failure does not silently switch to a more privileged path.

These are proposed checks, not results from a test we ran. Include repository and organization settings in the review rather than assuming every GitHub account has the same defaults.

Inspect indirect execution through dependencies and project scripts as well as explicit shell commands. Keep the final diff and the actual settings reviewed with the evidence.

Limitations and the acceptance decision

This method is not a complete supply-chain assessment. Runner isolation, third-party actions, dependencies, secret handling and deployment approvals require their own scrutiny. Platform behavior and defaults can change.

A useful handoff states which trust boundaries were inspected, which checks were executed, and what remains unknown. If approval is needed for a new privileged operation, obtain it explicitly; an instruction to fix failing tests is not an instruction to publish.

When selecting coding workflows in the OpenAgentSkill directory, look for this separation of responsibility. The strongest repair is not simply a green result. It is a result produced without giving the tested change unnecessary authority.