Run coding agents in GitHub Actions without trusting every issue

A public issue may ask an agent to work; it must not decide the agent's permissions. Run untrusted code in a restricted job, keep write credentials out of that execution environment, and pass only validated results into any privileged follow-up. A trusted workflow file does not make the issue text, pull-request files or generated output trustworthy.

For a hypothetical example, a maintainer wants an agent to investigate a failing parser test submitted by an outside contributor. The useful result is an explanation and a candidate patch. The agent has no reason to publish a release, change workflow permissions or read unrelated repository secrets.

That boundary has two input paths. The pull request can supply executable code. Its description can also supply text that influences the model's next tool call. Fixing only shell quoting leaves the second path open.

Keep untrusted content outside authority

Start with the event and the checked-out revision

GitHub distinguishes pull_request, which ordinarily uses the PR merge commit, from pull_request_target, which runs in the base repository's default-branch context. The latter is useful for trusted metadata operations such as labeling. GitHub warns against using it to build or execute untrusted PR code with privileged access. ^[1]

Here is the decision table we would use for the parser workflow. It is a proposed design, not a universal workflow template.

The event name is only the beginning. Follow each checkout, download and command. A trusted workflow can fetch a contributor's branch later; a harmless-looking test command can then execute its scripts. GitHub's focused pull_request_target guide identifies this checkout-then-execute combination as the decisive transition. It also warns that privileged issue_comment and workflow_run jobs can recreate the same risk. ^[2]

Actor approval does not cleanse the task description

Requiring a maintainer to request the agent's work is useful for controlling who starts it. It does not make every file or comment the agent later reads an instruction from that maintainer. In our example, the maintainer approves investigating the parser; the contributor still controls the reproduction and may update the branch.

A May 2026 research paper describes two relevant agentic-workflow patterns: untrusted event content entering an agent's prompt, and agent-derived output later influencing a script. Its authors report exploitable cases under their stated threat model. This establishes a researched failure pattern; it does not prove that a particular current action or NO FEED's proposed design is vulnerable. ^[3]

For the parser job, record the approved task and exact commit before work begins. Treat fetched issue bodies, source comments and test output as evidence to inspect. They cannot authorize a new credential, another repository or a publication step. Enforce those limits through the available tools and runtime permissions, because labeling text “untrusted” in a prompt does not remove an executable capability.

The proposed acceptance record identifies the input revision, resulting patch, commands run and remaining failures. If the PR head changes while the agent works, the result refers to the earlier revision; it should not silently become approval of the new one.

Separate reporting from execution

The default GITHUB_TOKEN permission should be minimal, with additional permissions granted only to the job that needs them. GitHub's documentation also notes that an action can access github.token even when the workflow does not explicitly pass the token as an input. Reviewing visible secret parameters alone is insufficient. ^[4]

In the proposed design, the investigation job produces a patch and structured findings. A reporting job may need permission to comment, but receives neither a command to run nor a request to execute the patch. Its inputs need validation: repository, PR number, commit identity, allowed artifact format and size. Generated prose remains content, not executable instructions.

This also constrains artifacts from a separate workflow. A successful completion status cannot certify every byte uploaded by code from a fork. GitHub explicitly tells privileged workflow_run consumers to treat those artifacts as untrusted. ^[2]

For shell-level inputs, GitHub recommends passing context through a suitable action argument or an intermediate environment variable rather than interpolating it into generated shell source. That addresses script injection; it does not prevent a model from choosing an inappropriate tool call. ^[5]

Review the runner and every executable dependency

A persistent runner can expose more than this repository's workflow secrets. GitHub warns that untrusted code can persistently compromise self-hosted runners and advises against using them for public repositories. Its guidance includes examining local credentials and network access to sensitive services. ^[5]

Our parser example therefore starts in a disposable environment with synthetic fixtures. Do not assume an ephemeral job erases what it could read or transmit while running. The runner's network routes and mounted resources still belong in the review.

For workflow dependencies, GitHub's current recommendation includes a dependency lockfile, now in public preview. It records exact commits and source repository identities, including transitive action dependencies; reusable workflows use the lockfile in their own defining repository. This is a preview feature to assess, not an assumed setting in an existing project. ^[6]

Where that mechanism is not adopted, GitHub recommends reviewed full-length commit SHAs rather than movable tags. Review the action's handling of repository data and secrets as well as its reference. ^[5]

The dependency depth also appears in practitioner discussion. On 15 May, Reddit user amouat, speaking about their work at Chainguard, described pinning internal action and container-image references and publishing a hardening report for each action. This was a disclosed commercial-product description, not an independent security comparison. It supplies a useful review question: what executes below the action named in your workflow? ^[7]

Check the current policy before the next run

As read on 19 October 2026, GitHub's default policy for certain public repositories is still evaluating pull_request_target restrictions; enforcement for affected repositories is announced for 2 November. It excludes private/internal repositories and does not replace an existing applicable event policy. A workflow running today is not evidence that it will keep running unchanged. ^[2]

Before enabling the parser agent, rehearse one ordinary request and one request containing a harmless instruction to perform an out-of-scope action against a disposable resource. Inspect attempted tools, service refusals and the reporting job's handling of malformed results. This is a proposed defensive check, not a claim that a small test proves resistance to all prompt injection. The release gate is simple: the agent can investigate the submitted code, while the submitted code cannot acquire the authority to publish itself.