GitHub Actions makes it easy to automate builds, tests, deployments, and other development tasks. But that flexibility also creates a security challenge: who should be allowed to start a workflow, and which GitHub events should be allowed to trigger it?
A workflow can run scripts, access repositories, use cloud credentials, publish packages, and deploy applications. If an unauthorized user or event can start the wrong workflow, the pipeline itself can become a security risk.
GitHub Actions now provides workflow execution protections to address this problem. These protections allow administrators to control both who can trigger workflows and which events are allowed to start them. GitHub made workflow execution protections generally available in September 2026 for enterprises, organizations, and repositories.
This article explains how the protection model works, when it is useful, and what developers and administrators should check before enabling it.
Why GitHub Actions Workflows Need Protection
A GitHub Actions workflow is usually stored as YAML under the .github/workflows directory.
For example:
name: Build and Test
on:
push:
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build
run: dotnet build
- name: Test
run: dotnet test
The on section determines which events can start the workflow.
That is useful, but the workflow file itself does not answer every security question.
For example:
Should every contributor be able to start a manually triggered workflow?
Should
pull_request_targetbe allowed?Should a deployment workflow be executable by every user with write access?
Should Dependabot or a GitHub App be allowed to run a particular workflow?
What happens if somebody changes the workflow YAML?
These questions become particularly important for repositories containing deployment credentials, cloud access, package publishing permissions, or other sensitive operations.
Workflow execution protections provide a policy layer above the workflow definition.
What Are GitHub Actions Workflow Execution Protections?
Workflow execution protections let administrators define an allowlist for workflow execution.
There are currently two primary rule types:
Actor rules — control who can trigger workflows.
Event rules — control which events are allowed to trigger workflows.
GitHub also supports targeting specific workflow files, which is useful when different workflows have different security requirements.
The important difference is that these rules are managed as policy rather than relying entirely on individual workflow YAML files.
A simplified model looks like this:
GitHub Event
|
v
Workflow Execution Policy
|
+---- Is the actor allowed?
|
+---- Is the event allowed?
|
+---- Does the policy apply to this workflow?
|
v
Workflow Run
If the execution request does not satisfy the configured policy, GitHub can prevent the workflow from running.
Actor Rules: Controlling Who Can Run a Workflow
By default, users with write access to a repository can trigger workflows.
That does not always match an organization's security requirements.
Consider a deployment workflow:
name: Production Deployment
on:
workflow_dispatch:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy
run: ./deploy.sh
The workflow uses workflow_dispatch, meaning it can be manually triggered.
In a development repository, allowing contributors to run this workflow may be reasonable.
For production deployment, however, the organization may want only a limited group of users or identities to execute it.
Actor rules can be used to define who is permitted to trigger the workflow.
GitHub's actor rules can cover identities such as users, repository roles, GitHub Apps, Copilot, and Dependabot.
This creates a useful separation:
Contributor
|
+-- Can modify code
|
+-- Cannot necessarily execute sensitive workflows
That separation can reduce the impact of an incorrectly configured workflow.
Event Rules: Controlling What Can Trigger a Workflow
Actor restrictions answer the question:
Who can run it?
Event restrictions answer:
What can start it?
GitHub Actions supports many workflow events, including:
pushpull_requestpull_request_targetworkflow_dispatchscheduled events
repository-related events
Event rules allow organizations to restrict which events are permitted for the workflows covered by a policy.
For example, an organization might decide that a sensitive workflow should not be started through workflow_dispatch by untrusted actors.
Another important case is pull_request_target.
Why pull_request_target Requires Special Attention
pull_request_target is useful because it runs in the context of the base repository rather than the merge commit of the pull request.
That can be necessary for workflows that need access to repository resources.
However, it also requires careful security review when workflows execute code influenced by an untrusted pull request.
GitHub has introduced a default protection for pull_request_target in public repositories. The default is initially evaluated before enforcement, with enforcement scheduled for November 2, 2026 for affected public repositories that were using the previous default behavior.
The practical lesson is simple:
Do not treat pull_request_target as just another workflow trigger.
Review exactly what the workflow executes and what permissions or secrets are available to it.
For example, this deserves careful review:
name: Pull Request Check
on:
pull_request_target:
jobs:
check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run script
run: ./scripts/check.sh
The security question is not simply whether the YAML is valid.
You also need to understand where the script comes from, what code is being executed, and what permissions the workflow has.
Workflow File Targeting
One of the important additions to general availability is the ability to target specific workflow files.
This matters because not all workflows have the same risk level.
For example:
.github/workflows/
ci.yml
tests.yml
release.yml
production-deploy.yml
A company might allow broad access to ci.yml and tests.yml while applying stricter execution policies to:
production-deploy.yml
This avoids treating every workflow in the repository as equally sensitive.
GitHub's current workflow execution protection model supports workflow file targeting, allowing policies to be scoped to particular workflow paths.
Evaluate Mode: Test Before Enforcing
One of the most useful features for administrators is Evaluate mode.
Changing a security policy directly from "nothing" to "block" can cause unexpected failures.
For example, suppose an organization creates this policy:
Allow:
Actors:
Release Team
Events:
workflow_dispatch
It might look correct on paper.
But existing repositories may contain legitimate automation that does not match the policy.
Instead of immediately enforcing the rule, administrators can use evaluation to see which workflow runs would be affected.
GitHub provides policy insights for this purpose. Active policies show blocked workflow runs, while evaluate policies can show runs that would have been blocked.
A safer rollout looks like this:
Create policy
|
v
Evaluate
|
v
Review affected workflows
|
v
Fix legitimate exceptions
|
v
Enable enforcement
|
v
Monitor
This approach is particularly useful for organizations with many repositories.
Join the conversation! Your thoughts help the community grow.