Open your organization's Settings, then Actions, then General, and set a policy. You can allow only your own actions and reusable workflows, or allow selected ones including GitHub-authored actions, verified creators and named entries. You can also require every action to be pinned to a full-length commit SHA.
The policy options
Under Policies in Actions settings, GitHub documents these choices:
| Option | Effect |
|---|---|
| Disable Actions | No workflows run |
| Allow only local | Actions and reusable workflows from your organization only. This also blocks GitHub-authored actions |
| Allow select actions and reusable workflows | Local ones stay allowed, plus the extras you tick |
Within the select option you can add three kinds of exception: actions created by GitHub, Marketplace actions by verified creators, and a list of specified actions and reusable workflows. The list takes up to 1,000 entries, written like owner/repository@tag-or-sha. Wildcards are allowed, entries are comma separated, and a leading exclamation mark blocks a pattern. Only listed items are allowed unless you add a wildcard.
Require SHA pinning
There is a separate setting to require actions to be pinned to a full-length commit SHA. GitHub says this applies to every action, including your own organization's and GitHub-authored ones. Reusable workflows can still be referenced by tag. A tag can be moved if someone gains access to the action's repository, while a full SHA cannot, which is why GitHub's hardening guide recommends it.
For workflows that use a dependency lockfile, GitHub notes the allow list checks the locked SHAs, so tag-based entries such as a version tag will not match locked dependencies. Use a wildcard or a full SHA in the list in that case.
Fork pull request workflows
On public repositories, choose an approval requirement for workflows from outside contributors. GitHub warns that the first-time contributor settings skip approval for anyone with a previously merged commit or pull request, so the "all external contributors" option is stricter. Workflows triggered by pull_request_target always run in the base branch context regardless of these settings.
A sensible starting point
- Switch to the select option, and allow GitHub-authored actions.
- List the third-party actions you actually use, by SHA.
- Turn on the SHA pinning requirement.
- Review the list when someone asks to add an action, as you would a new dependency.
Common mistakes
- Allowing a wildcard for a whole publisher, which trusts everything that publisher ships, now and later.
- Turning on the SHA requirement without telling teams, so every workflow fails at once.
- Forgetting reusable workflows, which are covered by the same policy but can still be referenced by tag.
- Granting repository admins the ability to override a policy the organization meant to enforce. GitHub notes that if the organization disables a policy, individual repositories cannot enable it, so set the policy at the organization level.
Treat the allow list as living inventory. Each entry should have an owner and a reason, and entries nobody uses should be removed.
Quick check
Will the SHA requirement break existing workflows?
Yes, any that reference tags. Update them to full SHAs first, or let a dependency update tool propose the changes.
Does an allow list make a listed action safe?
No. It limits what can run. You still need to read the code of actions you allow.
Safeguard inventories dependencies and can enforce policies and gates on pull requests, Try the free scan.
Sources
- GitHub Docs: Disabling or limiting GitHub Actions for your organization
- GitHub Docs: Secure use reference
Last reviewed: 19 October 2026.
