Ah, right. I'm in the camp of "Why not both?" for OSS public PRs: Make it safe for CI on external pulls by external users. To support the disneyification of sec

Ah, right. I'm in the camp of "Why not both?" for OSS public PRs: Make it safe for CI on external pulls by external users. To support the disneyification of security / smart defaults, make an easy button to infer the policy per workflow, such as based on the last X runs. However, instead of today's unsafe and chaotic set of checkbox rules & enforcements, tie that to an RBAC policy over user/role x workflow x capability, and cover the usual suspects of physical + logical resources that virtual & data envs typically protect. Ex: I'd expect the typical inferred public PR CI policy to be no creds/keys, a fixed set of network URL regexes (package deps like https://npm/@trusted_org/\ https://npm/@trusted_org/\*), upperbounds on CPU/memory/network/disk/etc, and ~no use of internal github APIs. There's probably surprises like `apt-get update`, which in turn is probably addressable with some common special cases. Likewise, for failure modes, as long as no creds are there and resource quotas are in place, most orgs are probably ok to make network read violations be WARN instead of HALT. That probably covers the 90-99% case when making public PR workflows much safer. For internal teams and higher-trust actions (CD, issue bots, ...), I'd expect the same but different. Currently, I'm not really sure how to do something like "Add a contractor but keep them away from most things" except by setting up a second repo with just CI. If there was RBAC and policy inference, however, that'd be all of 2 minutes.