GitHub Actions workflows can control important parts of a software delivery process, from running tests to publishing packages and deploying applications. As repositories and teams grow, simply defining permissions inside individual workflow files is often not enough.

GitHub now provides workflow execution protections that let administrators control who can trigger workflows and which events are allowed to start them. These policies can be applied at the enterprise, organization, and repository level. GitHub also provides Evaluate mode, which allows teams to test a policy before enforcing it.

This is especially useful when introducing a new policy to repositories that already have dozens or hundreds of workflows. Instead of immediately blocking runs, you can first see which workflows would be affected and fix legitimate exceptions.

Why Test a Workflow Rule First?

A security rule can look simple:

Only maintainers can manually run deployment workflows.

But the actual environment may be more complicated.

A repository might have:

A policy that works perfectly for one repository may block legitimate automation in another.

GitHub's Evaluate mode addresses this by running the policy in a non-enforcing state. The rule is evaluated against workflow activity, and policy insights show workflow runs that would have been blocked.

The rollout can therefore look like this:

Create rule
    |
    v
Evaluate
    |
    v
Review affected runs
    |
    v
Fix legitimate cases
    |
    v
Enable enforcement
    |
    v
Monitor

This is much safer than enabling a restrictive policy immediately.

What Can Workflow Execution Rules Control?

GitHub's workflow execution protections currently focus on two important dimensions:

  1. Actors

  2. Events

GitHub also supports targeting specific workflow files, which allows different policies to be applied to different workflows in the same repository.

Actor Rules

Actor rules control who is allowed to trigger a workflow.

Depending on the policy, this can include users, repository roles, GitHub Apps, Copilot, and Dependabot.

For example, an organization might decide that only maintainers should manually start a release workflow.

Event Rules

Event rules control which GitHub Actions events are permitted.

Common examples include:

on:
  push:

  pull_request:

  workflow_dispatch:

Other events, such as pull_request_target, can also be controlled through event policies.

This distinction is important because restricting a user and restricting an event solve different problems.

What Does Evaluate Mode Actually Do?

Evaluate mode is essentially a shadow test for your workflow policy.

Suppose you create this policy:

Policy: Restrict Manual Deployments

Allowed actor:
  Maintainers

Allowed event:
  workflow_dispatch

When the policy is active, a workflow that does not meet the rule can be blocked.

When the policy is in Evaluate mode, GitHub records the cases where the rule would have restricted workflow execution without applying the restriction. Policy insights can then be used to review those cases.

Conceptually:

                 Workflow Run
                      |
                      v
               Evaluate Policy
                      |
              +-------+-------+
              |               |
           Allowed          Would Block
              |               |
              v               v
         Run normally     Record insight

This makes Evaluate mode useful for discovering the real impact of a proposed policy.

Step 1: Inventory Your Existing Workflows

Before creating a rule, understand what already exists.

Start by reviewing the .github/workflows directory.

For example:

.github/
└── workflows/
    ├── build.yml
    ├── test.yml
    ├── release.yml
    ├── deploy-production.yml
    └── dependency-update.yml

Do not assume these workflows all have the same security requirements.

Create a simple inventory:

Workflow

Main Purpose

Trigger

Sensitive Access

build.yml

Build application

push

Low

test.yml

Run tests

pull_request

Low

release.yml

Publish package

workflow_dispatch

High

deploy-production.yml

Production deployment

workflow_dispatch

High

dependency-update.yml

Dependency maintenance

Automated

Medium

The exact classification will depend on the repository, but the exercise helps identify which workflows need stricter controls.

Step 2: Identify the Actors

Next, determine who or what actually triggers your workflows.

For a manual deployment workflow, you might have:

name: Production Deployment

on:
  workflow_dispatch:

Possible users could include:

GitHub notes that users with write access can generally trigger workflows unless actor restrictions are applied. Actor rules can separate the ability to contribute code from the ability to execute workflows.

This distinction is valuable for sensitive workflows.

A developer may need to push code but should not automatically receive permission to manually start a production deployment.

Step 3: Review the Events

Look at every on: declaration.

For example:

on:
  push:
  pull_request:
  workflow_dispatch:

Then ask what each event means for your repository.

A push workflow might represent normal CI.

A pull_request workflow may run against proposed changes.

A workflow_dispatch workflow may represent an intentionally manual operation.

A pull_request_target workflow deserves additional scrutiny because of its access to the base repository context and potentially sensitive resources. GitHub is introducing a default protection against pull_request_target in affected public repositories, initially through Evaluate mode, with enforcement scheduled for November 2, 2026.

Step 4: Create the Policy in Evaluate Mode

GitHub provides workflow execution policies under the Actions policy settings.

At the repository or organization level, the workflow is configured through:

Settings
  |
  +-- Actions
       |
       +-- Policies

At the enterprise level, Actions policies are managed from the enterprise policy area. GitHub's documentation identifies repository administrators, organization owners, and enterprise owners as users who can manage these protections.

When creating the policy, choose Evaluate where the option is available.

GitHub currently documents Evaluate mode as available for GitHub Enterprise Cloud.

Step 5: Target the Correct Workflows

One of the useful additions to general availability is workflow file targeting.

Suppose your repository contains:

.github/workflows/
├── ci.yml
├── tests.yml
├── release.yml
└── production-deploy.yml

You may not want the same execution policy applied to all four workflows.

For example:

CI workflows
    -> broad access

Release workflow
    -> restricted actors

Production deployment
    -> restricted actors + restricted events

GitHub's workflow execution protections allow policies to be scoped to specific workflow files.

This makes testing more precise because you can see the impact of the rule on the workflows that actually matter.

Step 6: Let Normal Automation Run

After the policy is configured in Evaluate mode, do not immediately start changing workflows just to make the policy pass.

Instead, allow normal development activity to continue.

For example:

  1. A developer opens a pull request.

  2. CI starts.

  3. A maintainer manually starts a release workflow.

  4. Dependabot creates an update.

  5. A scheduled workflow executes.

  6. A GitHub App starts automation.

The goal is to observe actual behavior.

This gives you more useful information than testing only one manually selected workflow run.

Step 7: Review Policy Insights

After enough workflow activity has occurred, review the policy insights.

GitHub provides insights showing workflow runs that would have been blocked by Evaluate policies. For active policies, the insights can show runs that were actually blocked.

Look for patterns such as:

Would Block
-----------
release.yml
Actor: developer
Event: workflow_dispatch

Would Block
-----------
dependency-update.yml
Actor: dependabot
Event: workflow_dispatch

The second case might be legitimate automation that needs to be added to the policy.

Do not treat every "would block" result as a problem. Some results may represent exactly the behavior you intended to prevent.

Step 8: Separate Expected Blocks From Unexpected Blocks

This is one of the most important parts of testing.

Create two groups:

Expected

These are workflow executions you intentionally want the policy to prevent.

Example:

Developer
    |
    +-- workflow_dispatch
          |
          +-- production-deploy.yml

If your policy is designed to prevent developers from manually deploying production, this is an expected block.

Unexpected

These are legitimate workflows that the new policy would interfere with.

Example:

Dependabot
    |
    +-- dependency workflow
          |
          +-- Would be blocked

If the repository depends on that automation, the policy needs to account for it.

This classification prevents teams from weakening a useful security policy simply because it reports blocked activity.

Testing workflow_dispatch

Manual workflows are a good starting point because their execution path is easy to understand.

Consider:

name: Release

on:
  workflow_dispatch:

jobs:
  release:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Build package
        run: dotnet pack

      - name: Publish package
        run: ./publish.sh

The workflow may have access to publishing credentials or other sensitive resources.

A policy could restrict who can trigger it.

Before enforcement, test:

Developer -> workflow_dispatch
Maintainer -> workflow_dispatch
Release automation -> workflow_dispatch

Then inspect the policy insights.

This provides a concrete view of whether your actor rule matches the actual workflow usage.

Testing pull_request_target

This trigger deserves special attention.

A simplified example is:

name: Pull Request Automation

on:
  pull_request_target:

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v7

      - name: Run checks
        run: ./scripts/check.sh

The security concern is not simply the trigger itself. The risk depends on how the workflow handles untrusted pull request content, credentials, scripts, permissions, and repository resources.

GitHub has been adding protections around this area, including safer actions/checkout behavior and a new default execution policy for public repositories.

If your organization has legitimate use cases for pull_request_target, Evaluate mode provides a way to identify affected workflows before a restrictive event policy is enforced.

Testing Actor and Event Rules Together

Actor and event rules can interact.

Consider:

Allowed Actor:
    Maintainers

Allowed Event:
    workflow_dispatch

A workflow execution is acceptable only when both conditions are satisfied.

Actor

Event

Result Under Policy

Maintainer

workflow_dispatch

Allowed

Developer

workflow_dispatch

Blocked

Maintainer

pull_request

Blocked

Developer

pull_request

Blocked

This is why testing only one dimension can give you an incomplete picture.

Always test the combinations that occur in your repositories.

Common Mistakes During Testing

Enabling Enforcement Too Early

The most obvious mistake is switching directly to enforcement without reviewing the impact.

Evaluate first when available.

Testing Only One Workflow

A policy that works for build.yml may cause problems for release.yml.

Test across the workflows included in the policy scope.

Ignoring Automated Actors

Do not test only human users.

Review automation such as Dependabot and GitHub Apps when those identities are part of your workflow architecture. GitHub specifically documents that identities associated with GitHub features may need to be included as allowed actors when custom workflows need to run under those identities.

Assuming a Block Is Always a Configuration Error

Some blocked executions are the desired result.

The purpose of the test is to determine whether the policy blocks the right things.

Making the Policy Too Broad

If only a deployment workflow requires strict protection, consider targeting that workflow instead of restricting every workflow in the repository.

Best Practices for Safe Rollout

Start With High-Risk Workflows

Begin with workflows that:

Use Small, Focused Policies

GitHub recommends creating multiple clearly defined policies and layering protections rather than building one large policy for an entire account.

For example:

Policy 1
Production deployments

Policy 2
Manual release workflows

Policy 3
Pull request event restrictions

This is easier to reason about than one complicated rule.

Keep an Exception List

During evaluation, document legitimate cases that require special handling.

For example:

Workflow:
    dependency-update.yml

Actor:
    dependabot[bot]

Required event:
    workflow_dispatch

Reason:
    Automated dependency release process

This makes the eventual policy configuration easier to review.

Re-Test After Changes

If you change the workflow or policy during evaluation, continue observing the results.

Do not assume the first evaluation reflects the final state.

Advantages and Disadvantages

Advantages

Disadvantages

Lets teams see potential impact before enforcement

Requires time to review workflow activity

Helps identify legitimate automation

Evaluate mode availability depends on GitHub plan

Reduces unexpected CI/CD disruption

Large organizations can generate many insights

Supports targeted workflow policies

Policies can become complicated if poorly structured

Useful for security and governance reviews

Requires ongoing maintenance as workflows change

A Practical Testing Checklist

Before enabling a workflow execution policy, verify the following:

[ ] All affected workflows have been inventoried
[ ] Workflow triggers have been reviewed
[ ] Sensitive workflows have been identified
[ ] Human actors have been identified
[ ] Automated actors have been identified
[ ] Evaluate mode has been enabled where available
[ ] Policy insights have been reviewed
[ ] Expected blocks have been separated from unexpected blocks
[ ] Legitimate exceptions have been documented
[ ] Workflow targeting has been reviewed
[ ] pull_request_target workflows have been checked
[ ] Production workflows have been tested separately
[ ] Enforcement impact has been reviewed

Summary

Testing GitHub Actions workflow rules before enforcement is mainly about understanding real workflow behavior before changing the security boundary.

Evaluate mode provides a practical way to do this. Instead of immediately blocking workflow runs, teams can observe which executions would be affected and use policy insights to determine whether the result matches the intended security policy.

The most reliable approach is to inventory existing workflows, identify their actors and events, create focused policies, evaluate them against normal workflow activity, and investigate the resulting insights.

This is particularly important for production deployments, release automation, workflow_dispatch, and pull_request_target.

A workflow policy should ultimately block the executions you consider unsafe while allowing the automation your development and delivery process genuinely depends on. Testing the policy first gives teams a safer way to reach that balance.