GitHub Actions adds stronger controls over who can run workflows
Workflow execution protections are now generally available, giving teams more precise control over who can trigger Actions workflows and which events are allowed to start them.
What changed
GitHub has moved workflow execution protections from public preview to general availability for GitHub Enterprise, organizations and repositories. Rules can now target individual workflow files, rather than applying only at repository level. GitHub has also added policy insights and a REST API for managing execution protections programmatically.
The release also introduces a security default for public repositories that do not already have an applicable event policy. GitHub is rolling out a rule that disables pull_request_target, initially in evaluate mode. For affected repositories still using the default policy, enforcement is scheduled for 2 November 2026.
Why it matters
Actions workflows often hold deployment credentials, package permissions and other sensitive access. Being able to restrict a deployment workflow without unnecessarily constraining routine CI gives security teams a more practical governance model. Evaluate mode is particularly useful because teams can see what a policy would block before enforcing it.
Buyer takeaway
For organizations evaluating GitHub as a development platform, this strengthens the governance case for keeping CI and deployment inside GitHub Actions. The important buyer question is not simply whether workflow controls exist, but whether they can be applied selectively, audited and managed at scale. This release materially improves all three.