Skip to main content
This guide shows how to configure and test enterprise-level policies for GitHub Actions. It covers the main policy options, how to specify allow/block lists, and a short workflow to validate enforcement. Open your enterprise account and go to Policies → Repository policies to begin. The screen lists repository-level policies and a button to create a new policy.
A GitHub Enterprise settings page for "NextGen Gaming" showing the Policies → Repository policies screen. It lists one repository policy named "repo-policy-1" with a left navigation menu of settings and a "New policy" button.

​
Actions policy — General tab

In the Actions policies’ General tab you choose which Actions and reusable workflows are permitted. The most common configurations are:
  • Allow all actions and reusable workflows (no creator restrictions).
  • Allow only enterprise actions and reusable workflows (actions created within repositories owned by your enterprise).
  • Allow only certain creators: GitHub-created actions, or Marketplace actions with a verified creator badge.
  • Specify an explicit allow/block list for particular actions or reusable workflows using comma-separated entries, wildcards, tags, or SHAs. Prefix an entry with ! to block it.
Table: Summary of common enterprise policy options Allow/block list examples (plain text input)

​
Marketplace “verified creator” badge

One recommended option is to restrict allowed actions to those with the Marketplace “verified creator” badge. That badge indicates GitHub has validated the publisher’s domain and email and that the publisher meets organization-level security requirements (for example, two-factor authentication).
A dark-mode screenshot of a GitHub Docs page titled "About marketplace badges." The page explains publisher domain/email verification for GitHub Marketplace and shows a note, warning, and an example badge.
The “verified creator” badge helps reduce risk from unverified third-party actions by confirming the publisher’s domain/email and basic security posture. Combining this with an explicit allow/block list gives fine-grained control.

​
Mixing policies

You can combine a broad rule (for example, “enterprise-only” or “verified creators”) with a specific allow/block list. Use ! to explicitly block an action that broader rules would otherwise permit. After you edit the policy, save it — the UI will confirm that the policy has been updated (for example, “Policy has been updated”).

​
Testing the policy

To validate your configuration, test it against a repository governed by the enterprise policy. The test below modifies a workflow to include:
  • actions/checkout
  • a local composite action
  • a deliberately unverified third-party action (to trigger blocking)
  • Super-Linter (a verified Marketplace action expected to be allowed)
Example workflow to test enforcement:
The Marketplace listing for Super-Linter is helpful if you need a fully featured example with permissions and checkout settings:
A dark-mode screenshot of the GitHub Marketplace page for the "Super-Linter" action. It shows the project title and description on the left and a sidebar on the right with version, verification badge, contributors and resources.
Commit this workflow to a branch (for example, main) and watch the Actions run. If your enterprise policy blocks the unverified action, the workflow will fail at startup with a policy-enforcement message indicating which actions were blocked.
Policy enforcement can cause workflow startup failures. Before enforcing strict policies in production, test in a staging environment and ensure required third-party actions are explicitly allowed or replaced with approved alternatives.

​
Diagnosing a blocked run

Open the failed run to inspect the startup failure and the enforcement message. The run page shows which steps were prevented from executing and why.
A GitHub Actions run page showing a failed workflow titled "Add Super-linter action to CI workflow" with a "Startup failure" status. The annotations mention an error that the specified action is not allowed by the repository/enterprise policy.
Example error text you might see:
If a blocked action must be permitted, add it to your enterprise policy’s allow list. Use exact owner/repo@ref identifiers or wildcards (for example, owner/*) to allow multiple actions. To explicitly deny an action that would otherwise be allowed, prefix it with !.

​
Other Actions settings to review

The Actions settings UI also includes additional controls you should consider:
  • Artifact and log retention (configure how long artifacts and logs are stored).
  • Approval requirements for workflows from forks or run by first-time contributors.
  • Controls for self-hosted runner usage and access.
  • Approvals/whitelists for reusable workflows.
A screenshot of a GitHub Actions settings page in dark mode. It shows retention settings (unused image retention 30 days, maximum version age 60 days, artifact/log retention 90 days) and options for approval of fork/first-time contributor workflows.

​
Best practices and resources

  • Start with a conservative policy (for example, verified creators + enterprise-only) and open up with explicit allow entries as needed.
  • Use staging repositories to test policy changes before applying them to production.
  • Maintain a documented allow list so teams understand which external actions are permitted.
  • Regularly review allowed actions and update versions (pinning by SHA or tag helps ensure reproducibility).
Helpful links Use these controls to reduce supply-chain risk from untrusted Actions while still enabling approved workflows your teams rely on.

Watch Video