Some of this is me just talking off the top of my head, so sorry for the rambling.
So my first response to this when I hear it from customers (and I have heard it before) is that is that something you really are concerned about (which implies a bigger culture issue and discussion)? Or is it something that hasn’t ever happened before, but we are playing “what if”. I always advocate highly for trusting your developers and team members to do the right thing in your DevOps journey, and then, if they don’t, then figure out the appropriate punishments and how to stop it in the future. That said, if you have already been burned by something like this, then I get it.
Second is that you have to be careful with giving people too much permission on self-hosted runners, for exactly that purpose I know, easier said than done.
So, let’s move on to “yes, we need to try and do something”. The problem you run into (which I know you know, but I’m restating for the broader audience), is that you can add a workflow to your branch, triggering on PR, and when you create your PR, it runs the workflow. So even the PR Regex Exclude action doesn’t help you here, because it is a workflow that triggers on a PR. So while it might be able to stop your PR from merging to main, it can’t stop that malicious workflow file from running because the PR was created.
Have you looked into environments? With environments, you can specify secrets, manual approvals, and even which branches can target that environment. I don’t think they will 100% solve this problem, but the manual approvals before the job can run might be able to help.
A really hacky option: Have an Action workflow or a GitHub App that listens for every push to the repo. Then have it examine the commits, and see if anything was added/modified/deleted from the workflows folder. If so, it could notify you. Again, not ideal.
I’m gonna throw this one at my team and see if they have any other thoughts. Sorry for the rambling.