The problem:

Secrets and external pull requests are fundamentally in tension.  If you allow CI runs of external pull requests to use secrets, someone could submit a PR that either does something malicious with those secrets directly in the CI configuration or leaks them to be used later.  If you don’t allow CI runs of external pull requests to use secrets, you often can’t run tests or other verification against them, increasing the risk when you merge.

The (possible) solution:

A malicions PR could abuse secrets if it were merged regardless.  What prevents that is that a project collaborator can look at the code before merging and verify that it’s not doing anything bad.

So really there needs to be a way to say “a trusted human has looked at this code and verified that it’s legit, please run CI with secrets”

PR approvals are an existing mechanism for this.  An approval basically means “a trusted human (collaborator) has looked at this code and verified that it does what it claims to do and meets all required standards”.  So allowing CI to run with secrets against an external pull request once it has been approved seems to solve the problem without introducing any new security risk.

My specific use case:

I develop open source extensions for closed source (and paid) software.  Distributing the libraries to build against publicly would constitute a breach of the license, so I can’t do that.  But I want others to be able to propose changes via pull request.