GitHub Actions workflow execution protections guide

Stop disallowed workflow runs before execution

Workflow execution protections decide whether an actor and event pass this gate. [2] Separate GitHub features can also hold certain workflow runs before execution. [6] [7] GitHub's automatic malicious-workflow hold currently applies to public repositories on GitHub.com, not GitHub Enterprise Server. [6] Job token permissions, workflow-file review, and runner isolation remain separate controls. [4] Approvals for jobs that reference a protected environment are another control. [14]

GitHub describes workflow execution protections as an allow list evaluated before a workflow run begins. An actor or event outside that policy does not reach execution. [2] That control sits above the YAML files and can cover a repository or a wider set of repositories through rulesets. [2]

An administrator can block a risky event across the chosen repositories before correcting every workflow file. [2] GitHub also supports evaluate mode, so the first policy pass can expose breakage without stopping current runs. [1]

Actor and event rules cover different trust decisions

Actions policies currently contain one policy type: workflow execution protections. That policy starts with two rule types, actor and event. [3] Treat them as separate review questions.

GitHub lists Read, Maintain, and Admin among the repository roles supported by actor rules. It also says every user with write access can trigger workflows by default. [2] Actor rules can make code access and CI execution authority distinct decisions.

Evaluate mode reveals policy impact before enforcement

Evaluate mode runs the rule without enforcing it and shows exactly what the rule would block. [2] GitHub says would-be blocked runs appear in policy insights. [5] Repository and organization setup pages place the policy under Actions, Policies. [2] [17]

An organization owner can also search the organization audit log with action:workflows.actions_policy_violation repo:ORG/REPO. [16] Inspect the actor, repository, timestamp, allowed, event_name, ruleset_ids, and violations. The event has no workflow-run ID. [11] Correlate each entry with policy insights or Actions history by repository, actor, and time. For enterprise rollout, an enterprise owner can use the enterprise audit log to view aggregated actions from every organization owned by the enterprise. [22]

1. Inventory the events used by every workflow in the target repository.
2. List the human roles, Apps, and bots that start those workflows.
3. Create actor and event rules in evaluate mode.
4. Exercise normal pull request, release, automation, and maintenance paths.
5. Review each would-be block in policy insights and adjust only the cases with a documented need.

A clean evaluate period means the policy matches the runs observed during that period. It does not cover a quarterly job, an incident-only workflow, or a rarely used release path unless those paths ran or were reviewed directly.

Event rules can block sensitive triggers across the selected scope

GitHub names push, pull_request, pull_request_target, and workflow_dispatch as event-rule examples. [2] The event list should match the repository's actual automation rather than every trigger a workflow author might choose later.

pull_request_target deserves a deliberate decision. Privileged workflows become vulnerable when they fetch or download and then execute untrusted code, dependencies, configuration, or artifacts. [13] A checkout by itself is not execution, and a workflow can ingest untrusted data without using actions/checkout. [13] The existing CI Tripwire pull_request_target guide covers the workflow-level boundary. An event rule adds a central gate before those workflows run. [2]

GitHub's changelog scheduled safer actions/checkout backport enforcement for July 20, 2026, but it does not confirm completed rollout. [8] Version 1 was excluded. [8] Inspect the exact checkout ref in each workflow; full-SHA, minor, and patch pins need an explicit update to receive a backport. [8] The allow-unsafe-pr-checkout: true input opts out and should be treated as a high-risk review finding. [13]

Actor rules separate repository access from workflow authority

Actor rules can allow individual users, repository roles, GitHub Apps, Copilot, and Dependabot. [2] A policy built only around human roles can block the automation identities that open maintenance pull requests or operate release workflows.

Build the actor list from run history and ownership records. Name the App or bot that needs access, the workflows it starts, and the repository scope where that access belongs. Broad role access is easier to configure, while named automation makes exceptions visible during review.

Record the current actor for every scheduled workflow. GitHub can reassign that actor after a default-branch change. [20] A user with write access who changes the cron schedule of a deactivated workflow reactivates it and becomes its actor. [20] A scheduled workflow linked to an Enterprise Managed User stops if that actor is deprovisioned. [20] Retest the schedule after any of those changes.

Actor rules control who can trigger workflows. [2] An allowed but compromised user or App can still pass that identity check. GitHub cites compromised credentials as one reason it separately holds some public-repository workflow runs for approval. [6] Protect those credentials, narrow GitHub App permissions, and monitor allowed identities.

CODEOWNERS can require approval before a pull request merges when a branch protection rule enables that review. [15] Treat workflow-file merge review and actor rules as separate controls.

Keep the GITHUB_TOKEN permissions at the smallest job boundary. [4] Pin third-party actions to reviewed full-length commit SHAs verified against the action repository. [4] For untrusted code on self-hosted compute, use an isolated environment that is not reused across runs and cannot reach internal resources. [13]

A repository-first rollout keeps the first policy bounded

At repository level, GitHub places the feature under Settings, Actions, Policies. The setup flow creates a ruleset, adds actor and event rules, then saves it in active or evaluate mode. [2]

Start with a repository whose workflows and owners are known. After evaluation covers the repository's uncommon paths, consider moving the same decision to organization or enterprise scope. At enterprise level, open Policies, Actions, then Policies. [21] Workflow execution protections use rulesets and can target repositories through repository custom properties. [3]

Inventory repository, organization, and enterprise rulesets before promotion. Source [10] establishes aggregation for branch and tag rulesets only. This guide makes no assumption about Actions-policy overlap behavior. Verify overlapping Actions-policy scopes in evaluate mode before reconciling or retiring the repository-level policy. [10]

Custom-property targeting creates a changing repository set. Name the property owner and decide whether repository users or Apps may update its value. [12] Record the expected matched repositories. For organization scope, use the custom_property_values organization webhook or an installed GitHub App as a change signal. [18] Paginate through every response page from GET /orgs/{org}/properties/values. [19] For enterprise scope, configure that webhook or App coverage across every targeted organization. [18] Enumerate every targeted organization and paginate the endpoint separately for each one. [19]

Keep the policy name specific, record its owner, and attach the reason for every exception. A future maintainer needs to know whether an allowed event supports production delivery, dependency automation, or an abandoned workflow.

Activation needs evidence from normal and uncommon runs

• Every workflow event in the repository has an allow, block, or documented exception decision.
• Human roles, GitHub Apps, Copilot, and Dependabot have been considered separately.
• Allowed identities have credential protection, narrow permissions, and monitoring.
• Evaluate mode covered pull requests, releases, maintenance jobs, and manual operations.
• Direct expression interpolation from untrusted contexts into scripts has been removed in favor of action inputs or quoted intermediate environment variables. [4]
• The policy scope targets only the repositories reviewed for this rule.
• Custom-property ownership, mutability, expected matches, and change monitoring are recorded.
• Overlapping Actions-policy scopes have been tested in evaluate mode without assuming precedence.
• The rollback owner and the path for changing the ruleset from active to evaluate mode are recorded before activation. [2]

After activation, trigger one known-allowed canary. If actor and event rules are both configured, test a denied actor with a known-allowed event, then an allowed actor with a denied event. Each denied canary should fail to reach execution under the policy. [2] For an organization-owned canary repository, confirm each denial with a workflows.actions_policy_violation audit event matched by repository, actor, event, and ruleset. [11] Observe normal automation through the team's chosen monitoring window and record the result.

If rollback is needed, the recorded owner changes the ruleset from active to evaluate mode and saves it. [2] Then rerun the harmless actor or event path that active enforcement blocked and verify that it executes. A canary that was already allowed cannot prove enforcement was removed.

As of August 5, 2026, GitHub documents Actions policies and workflow execution protections as public preview features that are subject to change. [3] Recheck the current documentation before copying this setup into a permanent organization standard.

Related reviews: GitHub Actions security risks, pull_request_target security, and reusable workflow security.

CI Tripwire Editorial has not commissioned independent expert review of this article. Read more about the organization byline at contributors and the source posture at sourcing.

Corrections can be routed through the corrections note. Sources: 22 official GitHub primary-source entries across 21 underlying documents, last reviewed 2026-08-05.