GitHub Separates Who Writes Code From Who Runs Your CI

GitHub has introduced new features to separate who writes code from who runs your CI (Continuous Integration) processes. This change aims to prevent compromised accounts or malicious pull requests from turning a CI pipeline into an attack path. Previously, anyone with write access to a repository could trigger a GitHub Actions workflow, which could lead to security risks.

The company first previewed this feature on June 18 and made it generally available on September 17 for GitHub Enterprise, organizations, and repositories. Workflow execution protections allow administrators to build an allowlist, specifying which users, roles, GitHub Apps, Dependabot, and events are authorized to trigger workflows. If an actor or event is not on the allowlist, the workflow run will not start.

There are two types of rules: actor rules control who can trigger workflows, including individual users, repository roles, GitHub Apps, Copilot, and Dependabot, while event rules control which events are allowed, such as push, pull_request, pull_request_target, and workflow_dispatch. Administrators can target specific workflow files instead of entire repositories, giving teams more granular control over who can run certain workflows.

In addition to the allowlist, GitHub has added insights to show how rules are evaluated and enforced at different levels, including enterprise, organization, and repository. These insights help administrators tune policies before and after they go live. A new REST API supports creating, reading, updating, and deleting policies at all three levels.

Admins can enable policy-driven execution using the evaluate mode, which allows them to "run your rules in shadow, so you can see exactly what a rule would block before you enforce it." One caution from the documentation is that bots like dependabot must be added as allowed actors if your workflows depend on them.

Currently, the default rule for pull_request_target runs the workflow with the base repository's token and secrets. This can be a security risk if a workflow checks out code from an untrusted fork. GitHub has already tightened the actions/checkout feature to refuse fetching fork pull request code unless a developer sets allow-unsafe-pr-checkout in June.

A default rule disables pull_request_target in public repositories that don't already have an event policy, and it will enforce this rule starting November 2, 2026, in evaluate mode. Enforcement will begin on November 2, 2026, but it will not apply to private or internal repositories.