Anyone with write access to a repository can trigger a GitHub Actions workflow. That has been the default since Actions launched. It’s convenient. It’s also a problem when a compromised account or a malicious pull request can turn your CI into an attack path.

Attackers have noticed. GitHub’s own 2026 Actions security roadmap points to incidents involving tj-actions/changed-files, Nx, and trivy-action as examples of the same pattern. Go after the automation, not the application. Steal a token, and you own the pipeline.

Mitch Ashley, vice president and practice lead for CIO & technology buyers and software lifecycle engineering at The Futurum Group, puts the stakes plainly. “A single compromised developer account can mean the difference between a well-running pipeline and compromised software.”

GitHub’s latest answer is now generally available. On September 17, the company made workflow execution protections GA for GitHub Enterprise, organizations, and repositories. The feature first appeared in public preview on June 18.

The idea is simple. Administrators build an allowlist. GitHub checks the rules before a workflow run begins. If the actor or the event isn’t on the list, the run doesn’t start.

There are two kinds of rules. Actor rules control who can trigger workflows. These can be individual users, repository roles such as Read, Maintain, and Admin, GitHub Apps, Copilot, and Dependabot. Event rules control which events are allowed, including push, pull_request, pull_request_target, and workflow_dispatch.

GitHub’s documentation explains the point of actor rules this way: “Actor rules let you separate who contributes code from who runs your CI, so you can grant a contributor write access without granting them the ability to execute workflows.”

Write access and execution rights used to arrive as a bundle. Three features in the GA release weren’t in the preview.

First, rules can now target specific workflow files instead of a whole repository. A team can limit deploy.yml to a named group while leaving CI workflows open to every contributor.

Second, there are new insights. They show how rules are evaluated and enforced at the enterprise, organization, and repository level. Admins can use them to tune a policy before and after it goes live.

Third, there’s a REST API. It supports create, read, update, and delete at all three levels, including workflow path conditions. Teams that manage governance as code can keep these policies in the same review process.

Evaluate mode carries over from the preview. It lets admins “run your rules in shadow, so you can see exactly what a rule would block before you enforce it,” according to the June announcement. GitHub’s docs list evaluate mode as an Enterprise Cloud capability. Rules live under Settings, then Actions, then Policies. They build on GitHub’s rulesets, so enterprise-wide policies and custom-property scoping work as they do elsewhere. The protections cover all public repositories, plus private repositories on GitHub Team or GitHub Enterprise.

One caution from the docs: bots such as dependabot[bot] must be added as allowed actors if your workflows depend on them.

Ashley sees the value in the simplicity. “Often the simplest solutions can be the most effective. Tighter controls over how CI or deployment to test or production is executed greatly reduce the attack surface. With these improvements, dev teams will no longer have to rely upon bespoke built solutions to secure this aspect of their development pipelines.”

The part with a deadline is the new default rule for pull_request_target.

This trigger runs with the base repository’s token and secrets. If a workflow checks out code from an untrusted fork, the attacker’s code can run with those privileges. GitHub already tightened actions/checkout in June so that version 7 refuses to fetch fork pull request code in these workflows unless a developer sets allow-unsafe-pr-checkout.

A default rule disables pull_request_target in public repositories that don’t already have an event policy. It’s running in evaluate mode today. Enforcement starts November 2, 2026. It doesn’t apply to private or internal repositories.

That’s about six weeks. Here’s how to use them.

Search your .github/workflows directories for pull_request_target. Then check the policy insights page to see which runs the default would have blocked. Some workflows only post a comment using trusted code from the base branch. Those are low risk. Others check out pull request code while holding secrets. Fix those first.

For workflows that truly need the trigger, you have two options. Add an event policy that allows pull_request_target only for named workflow files. Or restructure. Run the untrusted analysis in a read-only pull_request job, save the results as an artifact, and post comments from a separate workflow_run job that has write access. The second path takes more work, but it removes the risk.

One analysis from Digital Applied flags AI code-review bots and labelers as the likeliest to be caught. They read pull request text from strangers while holding write tokens.

Policy-driven execution is one item on GitHub’s Actions security roadmap. Workflow dependency locking, scoped secrets, and a native egress firewall are still coming. This is the first piece most teams can use today.

The larger point is about how teams think of CI. Pipelines hold deployment credentials, signing keys, and cloud access. They deserve the same scrutiny as production.

Start in evaluate mode. Read the insights. Then turn rules on for the workflows that matter most.