The normal thing is to have integration test PRs and other CI actions (which may require access tokens to APIs, inherently or due to naive design) be defined by

The normal thing is to have integration test PRs and other CI actions (which may require access tokens to APIs, inherently or due to naive design) be defined by the incoming branch, creating a vector for an attacker to get access to privileged resources. For certain parts of integration and testing jobs that are operating on untrusted code, it'd therefore be desired to not allow incoming PRs to change certain parts of the CI configuration (not only including .github/workflows, which can be protected using branch protection rules, but the testing framework). It's possible to achieve this by splitting up your workflows and using workflow_run but it's non-obvious and finicky enough that I very rarely see it done. GitHub could make this easier and propose better patterns than they do in their attempt to address the problem[0], which I think could use a 2023 follow-up. [0]: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/ https://securitylab.github.com/research/github-actions-preve... --- In this context, an iMessage message <> a GitHub PR, I guess.