Suppose a pull-request build uploads a ZIP and a second workflow downloads it with permission to publish a release. Before that second job unpacks the archive, you need to know who controlled its contents and which command will use them. A green build tells you neither.
GitHub's workflow_run documentation, reviewed October 19, 2026, says the follow-on workflow can access secrets and write tokens even when the earlier workflow could not. A successful build is therefore insufficient evidence that its output belongs in a privileged execution context.
Our earlier deployment-credential walkthrough follows the job's authority. This review starts at the artifact download and follows the file to its consumer.
An artifact name does not identify a trusted producer
For one artifact your release pipeline consumes, record its repository, workflow run, source commit, and event. Then read the download step. Does it select the artifact from that exact triggering run, or search for a matching name across runs?
A run-bound download avoids confusing one run's output with another. It still says nothing about whether the producing code was trusted. An artifact name such as release-build is chosen by a workflow; the name is not an authorization decision.
GitHub also documents that a workflow_run trigger for completed can run regardless of the earlier workflow's conclusion. If the consumer should run only after success, make that condition explicit. Treat it as an operational filter, not a security proof: untrusted code can produce an artifact while passing its own tests.
A test summary needs a data parser
Consider a hypothetical pull-request workflow that uploads a test summary. A privileged follow-on job downloads it to post a comment. That job should need a small data record, not an executable program supplied by the contributor.
For this example, define the expected fields, types, and maximum size before parsing the file. Reject extra files and unexpected structure. Keep report text as data when constructing the comment; do not interpolate it into a shell command. These are recommended design constraints for the example, not protections automatically supplied by GitHub.
The same artifact becomes a different risk if the consumer sources a script from it, runs its binaries, loads its configuration into a tool that executes hooks, or deploys its contents. Review the actual downstream command rather than classifying every ZIP download as equally safe or equally dangerous.
Archive paths can reach the job’s working files
An archive introduces filenames as well as file contents. Review the extraction library's handling of paths and links, and keep the unpacked files out of directories the privileged job uses as trusted code or configuration.
GitHub Security Lab's guidance on preventing pwn requests, reviewed October 19, 2026, distinguishes consuming untrusted data from executing untrusted output. Its example associates the download with the triggering run and uses temporary storage. Those choices help preserve the boundary; they do not turn arbitrary artifact contents into trusted instructions.
If your consumer needs only a JSON summary, give it a dedicated temporary directory and a deliberately narrow parsing path. It should not have to unpack a complete application workspace to read a test count.
Rejected inputs need test coverage
In a disposable repository with no production secrets, exercise the consumer with an unexpected filename, malformed data, an oversized record, and a run that does not meet the release rule. The expected outcome is a clear refusal before the privileged action.
Record which rule each case tests. A parser rejecting malformed JSON does not establish that an archive extractor is safe, and a successful extraction does not establish that the producer was authorized to supply production code.
Before enabling the privileged job, have its owner review the producer restriction and the rejection tests together. If the consumer executes downloaded code, that review must authorize the code’s source as well as the workflow that delivered it.