Who has permission to workflow_dispatch

[lpoulter]

I couldn’t find anything in the docs about this.

When adding a workflow that is triggered on workflow_dispatch who has permissions to trigger that workflow for any given repo and is there a way to custom that permission?

[kingthorin]

I believe anyone with collaborator or greater can do it, however, you can also add an if statement to check who the github.actor is.

Will add more detail shortly, on mobile right now.

[weide-zhou]

Hi @lpoulter,

The use should have write access to the repo, eg: collaborators, any organization people/team member who is given write access.

Github action event can be triggered via rest api, so if you create a personal access token with repo scope, anyone has the token can trigger the workflow. Please check the doc here for more details.

Thanks

[kingthorin]

You can check who is triggering the workflow:
if: github.actor == 'lpoulter' || github.actor == 'kingthorin'
or
if: contains('["kingthorin","lpoulter"]', github.actor)

Example here: https://github.com/OWASP/www-project-web-security-testing-guide/blob/53d24199a86ef59888ad8b91d8a173468d862753/.github/workflows/pr_comment.yml#L10
It’s slightly different, it runs for anyone other than the actors we check, but same basic idea. (!= vs ==.)

Sadly there isn’t (currently) a way to check if your team or a specific role contains the github.actor. I’ve submitted an enhancement request that they add something like @organization/some-team.contains(github.actor). Just as I’m writing this reply it occurs to me that something like github.actor.role == 'Maintainer' might also be handy.

Edit: There’s also some more details from GitHub staff here: Who can manually trigger a workflow using workflow_dispatch :

To trigger a workflow in a repository, the user should be a collaborator with Write permission in the repository. Normally the external users can’t trigger workflows in the repository.
If the external users use a pull request to trigger workflow from the forked repository, the GITHUB_TOKEN only has read permissions for some scope.

[mikemhenry]

What would stop some with write access to repo from modifying the CI yml to add themselves to the list of users who can trigger the workflow_dispatch action?

[akmalharith]

CODEOWNERS

[gavinclarkeuk]

CODEOWNERS isn't sufficient as you could still update the workflow on a branch without raising a PR. You need to create a ruleset to block pushes to the .github directory on all branches, with a bypass for specified users/repo admins

[PaulRBerg]

As an alternative to @gavinclarkeuk's solution, you could also create a deployment environment that targets only protected branches.

You make your GitHub secrets available only in that environment, which is tethered to your protected branches, e.g., main.

In this way, if someone changes the workflow logic on a non-protected branch, they cannot access the GitHub secrets available only in the deployment environment (even if they trigger the workflow via workflow_dispatch).

[kingthorin]

@PaulRBerg great suggestion!

[kingthorin]

Nothing. But if you don’t trust those that have write access there would seem to be different/bigger issues.

You could set branch protection and also enable it for admins. (Though similarly that could also be disabled by other admins.)

[mark-jordanovic-lewis]

Untrue, there is the principle of least permissions. Writing to a code repository and triggering a workflow are two different actions. There is nothing to do with trust involved in that.

[mikemhenry]

Branch protection might work. Maybe I should open a new issue/post but I’ve got an action that costs $ to run so I’d like for admins to be the only ones to be able to run it so I’d like to prevent those with only write privileges from being able to accidentally running it. Granted changing the yml is no accident but I just like to put as many engineering controls possible in place to prevent mistakes.

Someday I’d like to have this working in a way where someone random could fork and make a PR, CI automatically runs free CI action and after review admin triggers expensive CI action.

[fschroder-slyp]

Hey @kingthorin
Is there a link you can share for the enhancement request? We’re looking exactly for this functionality.
Cheers

[kingthorin]

Sadly I don’t have a reference. It was submitted via the feedback form and I never heard anything further.

Please feel free to re-use any of the text in my post or reference that I’d asked for it at some point and you’d like to +1 it 😀 Whatever helps you/the community most ❗

[franpb90]

I created this discussion Running workflows on dispatch should have their own permission from what I think is a good solution.

[boxrick]

I wrote a composite action to do this, perhaps someone will find it useful. You can check and limit your run to TEAMs.

github.actor is who triggered the pipeline

inputs TEAM and ORG will be specific to you, and the token will need org read permissions

curl -s -o /dev/null -w "%{http_code}" -H "Authorization: token ${{ inputs.auth_token }}" "https://api.github.com/orgs/${{ inputs.org_name }}/teams/${{ inputs.team }}/memberships/${{ github.actor }}"

Then check for a 200 response or not and output that as part of the step

[dannybarnes]

The new Actions Policies feature just released solved this issue for me:

https://github.blog/changelog/2026-06-18-control-who-and-what-triggers-github-actions-workflows/

[franpb90]

It looks promising.

[mathew-rumsey-tylertech]

Without the ability to limit a policy to specific workflows, it sadly will not work for us. We need to restrict regular contributors from dispatching sensitive workflows while retaining the ability for their PRs/merges to trigger other CI workflows.

[bashonly]

I'm still trying to figure out how the actions policies feature is actually useful to anyone in its current incarnation.