For most of 2026, GitHub Actions has been the attack surface security teams could not fully close. A forked pull request, a crafted workflow_dispatch call, a compromised bot account, any of these could trigger a pipeline holding deployment keys, cloud credentials, and signing secrets. GitHub has now shipped a direct answer: workflow execution protections, in public preview across Enterprise, organisation, and repository levels, let administrators define precisely who and what is allowed to start a run.

What actually changed

Workflow execution protections are built on the same rulesets framework GitHub already uses for branch and tag protection, which means the targeting model is familiar to anyone who has locked down a repository before. Actor rules control who can trigger a workflow, individual users, specific repository roles such as Read, Maintain, or Admin, GitHub Apps, Copilot, or Dependabot. Event rules control which triggers are permitted at all, push, pull_request, pull_request_target, and workflow_dispatch among them. Anything outside the allow list simply never runs, evaluated before execution starts rather than caught after the fact.

A rollout mode matters as much as the feature itself. Rules can be set to evaluate mode first, where nothing is actually blocked but every run that would have been stopped is logged in policy insights. That gives platform teams a way to see the blast radius of a new policy against real traffic before they flip it to enforce, which is the difference between a security control that ships and one that gets rolled back after breaking a release on day one.

Why this had to happen

Read next to the year GitHub Actions has had, the timing is not a coincidence. The Cordyceps flaw let any GitHub account hijack CI/CD pipelines at Microsoft, Google, and Apache by abusing how workflows resolved trigger permissions. Separately, CVE-2026-3854 gave attackers a path to full control of GitHub Enterprise Server through a single crafted git push, with the majority of instances still unpatched weeks after disclosure. Both incidents shared the same underlying weakness: workflow trigger logic that assumed good faith from anything capable of opening a pull request or pushing a branch. Workflow execution protections are GitHub’s structural fix to that assumption, not a patch for either specific bug, which is exactly why the feature is worth adopting even if neither incident touched your organisation directly.

The gap between shipping and enforcing

A feature in public preview does not protect anyone by default. It has to be configured, tested in evaluate mode against real workflow traffic, tuned so legitimate automation from bots and integrations keeps working, and then switched to enforce with a rollback plan ready. For organisations running dozens or hundreds of repositories with inconsistent ownership, that is a genuine project, not a settings toggle, and the ones who treat it as a checkbox will find out what they missed during an incident rather than during testing.

What we recommend

• Inventory which actors and events currently trigger workflows across your repositories, including third-party Apps and bots you may have forgotten were granted access
• Enable workflow execution protections in evaluate mode first, and review policy insights for at least one full sprint before enforcing anything
• Pay particular attention to pull_request_target and workflow_dispatch triggers, the two event types most commonly abused in this year’s supply chain incidents
• Extend the same allow-list discipline to any self-hosted runners, since execution protections at the trigger level do not replace runner isolation
• Treat this rollout as an opportunity to retire unused bot accounts and Apps with write access rather than simply adding them to a new allow list

If your organisation runs GitHub Actions at scale and needs help auditing workflow triggers, rolling out execution protections without breaking existing pipelines, or hardening CI/CD more broadly after a year of supply chain incidents, contact Excello Digital. We help European engineering teams turn CI/CD from an open attack surface into a controlled one.