Skip to main content
Skip to content

Controlling who can execute GitHub Actions workflows

Control who can trigger GitHub Actions workflows and which events are permitted to run them across an enterprise, organization, and repository.

Wer kann dieses Feature verwenden?

Repository administrators, organization owners, and enterprise owners

All public repositories, and private repositories on GitHub Team or GitHub Enterprise.

Informationen zu den Actions-Richtlinien

Mithilfe von Aktionsrichtlinien können Sie steuern, wie GitHub Actions Workflows in Ihren Organisationen und Repositorys ausgeführt werden. Sie konfigurieren Aktionsrichtlinien in einem neuen Abschnitt Ihrer GitHub Actions Einstellungen, getrennt von den vorhandenen allgemeinen Einstellungen.

Aktionsrichtlinien sind auf Unternehmens-, Organisations- und Repositoryebene verfügbar.

Aktionsrichtlinien enthalten derzeit einen Richtlinientyp: Workflowausführungsschutz. GitHub plant, im Laufe der Zeit weitere Richtlinien hinzuzufügen.

Informationen zu Schutzmechanismen für die Workflow-Ausführung

Mit Workflowausführungsschutz können Sie eine Zulassungsliste definieren, die steuert, wer Workflows auslösen GitHub Actions kann und welche Ereignisse sie ausführen dürfen. Workflowausführungsschutz umfasst zwei Regeltypen: Ereignis und Akteur. GitHub plant, im Laufe der Zeit weitere Regeln hinzuzufügen.

Die Schutzmechanismen für die Workflowausführung basieren auf dem GitHub-Framework für rulesets, sodass das Targeting, das Sie bereits von rulesets kennen, auch hier funktioniert. Mithilfe von benutzerdefinierten Repositoryeigenschaften können Sie Schutzmaßnahmen mit Regelets anwenden und auf bestimmte Repositorys beschränken. Weitere Informationen zu Regelsätzen finden Sie unter Informationen zu Regelsätzen. For more information, see About Actions policies.

Hinweis

GitHub has added a default policy that will block the pull_request_target event in public repositories. This policy will be enforced on November 2, 2026. See Sichere Verwendung von pull_request_target.

Preparing to add protections

Like rulesets, workflow execution protections layer with other protections in the same repository, organization, or enterprise.

Rather than creating one large policy per account, we recommend creating multiple clearly defined policies and layering protections across account levels. Enterprise owners can create protections at the enterprise level for broad, non-negotiable policies. Organization owners and repository administrators can then add to these restrictions.

For each policy you define, think about:

  1. Which organizations or repositories your protection will target. For example, open source repositories may need tighter restrictions on who can trigger workflows. You can target repositories by factors like visibility, deployment status, or custom property.

  2. Which workflows will be protected. For example, workflows that deploy production code might need a certain level of protection, but less sensitive automations may not need the same level of protection. You can scope policies to specific workflow paths or required workflows.

  3. Who should be able to run these workflows in the repositories you're targeting. This might be users with a certain role, selected bot accounts, or a specific team. Consider grouping these users in an organization or enterprise team so they can be easily contacted and referenced across multiple rulesets. See Erstellen eines Organisationsteams or Erstellen von Unternehmensteams.

Creating a workflow execution policy

First, create a new Actions policy for the account level you're working at.

In a repository or organization:

  1. Click the Settings tab.
  2. In the left sidebar, under Actions, click Policies.

In an enterprise:

  1. Click the Policies tab.
  2. In the left sidebar, click Actions, then Policies.

Tipp

To manage policies programmatically, see REST API endpoints for GitHub Actions policies.

Configuring the policy

Next, create a new policy.

  1. Choose a name for the policy.
  2. Choose an enforcement status. If you select Evaluate (GitHub Enterprise Cloud only), you will be able to monitor when users would hit the restriction in policy insights.
  3. Target your desired workflows, organizations, or repositories.
  4. Configure the following workflow execution protections.

Restrict actors

By default, every user with write access to a repository can trigger workflows. Actor rules let you separate who contributes code from who runs your CI, so you can grant a contributor write access without granting them the ability to execute workflows.

Only the allowed actors will be able to run the specified workflows in the targeted repository. If you also restrict events, these users will only be able to trigger workflows with the allowed events. Non-allowed actors will not be able to run the specified workflows at all.

GitHub features are exempt from these restrictions for the built-in processes that they run on GitHub Actions. However, if you have created workflows that need to be run by the identity associated with a GitHub feature, such as dependabot[bot], then this identity must be added as an allowed actor.

Restrict events

Event rules control which events are permitted, such as push, pull_request, pull_request_target, and workflow_dispatch.

Evaluating policies

You can view policy insights to see workflow runs that have been blocked (for active policies) or would have been blocked (for "evaluate" policies). This is a good way to check that policies are working as intended and not causing unnecessary friction.

To view insights, click the Policy insights page. You'll find this directly under the page for GitHub Actions policies in your repository, organization, or enterprise sidebar.