Handle untrusted input and forks

Start from the behavior you can observe. Fork code is tested without production secrets, and a trusted follow-up workflow consumes only verified outputs.

Repository events can combine untrusted content with secrets or write tokens, especially around fork workflows and privileged event types. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to check out and execute fork code in a context carrying repository secrets. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to separate untrusted execution from privileged work and validate every artifact or value crossing that boundary. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Reduce workflow authority and prevent untrusted repository input from becoming privileged code execution. Record enough evidence that another developer can repeat the result without relying on your memory.

Threat-model a malicious pull request that changes tests, package scripts, artifact contents, and its title. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.