Repo sync

content/actions/concepts/about-actions-policies.md

@@ -0,0 +1,59 @@
+---
+title: About Actions policies
+shortTitle: Policies
+intro: Govern how {% data variables.product.prodname_actions %} workflows run within your repository, organization, or enterprise.
+versions:
+  feature: workflow-execution-protections
+contentType: concepts
+redirect_from:
+  - /repositories/managing-your-repositorys-settings-and-features/actions-policies/about-actions-policies
+  - /organizations/managing-organization-settings/actions-policies/about-actions-policies
+  - /admin/enforcing-policies/enforcing-policies-for-your-enterprise/actions-policies/about-actions-policies
+  - /repositories/managing-your-repositorys-settings-and-features/actions-policies
+  - /organizations/managing-organization-settings/actions-policies
+  - /admin/enforcing-policies/enforcing-policies-for-your-enterprise/actions-policies
+---
+
+## About Actions policies
+
+Actions policies let you govern how {% data variables.product.prodname_actions %} workflows run. You can configure them in the **Policies** section of your {% data variables.product.prodname_actions %} settings (separate from the **General** settings).
+
+Actions policies are available at the enterprise, organization, and repository levels. They currently contain one type of policy: workflow execution protections. {% data variables.product.github %} plans to add more policies over time.
+
+## About workflow execution protections
+
+{% data reusables.actions.actions-policies-about-body %} These protections can disrupt several real-world attack patterns:
+
+* **Poisoned pipeline execution from pull requests.** Restrict or prohibit `pull_request_target`, including in public repositories where it is most often exploited.
+* **Manual-trigger abuse.** Limit `workflow_dispatch` so untrusted identities cannot start workflows.
+* **Untrusted-actor execution.** Block low-trust identities from triggering workflows entirely.
+* **Misconfiguration exploitation.** Apply central policy that overrides any single misconfigured workflow file.
+
+When enforced, disallowed workflow runs will fail with an error. For example:
+
+``` text
+Event 'workflow_dispatch' is not allowed to trigger Actions workflows. Workflow file: '.github/workflows/0-welcome.yml'.
+```
+
+<!-- expires 2026-11-02 -->
+
+{% ifversion default-pull-req-target-policy %}
+
+> [!NOTE] {% data reusables.actions.workflows.pull-request-target-policy %}
+
+{% endif %}
+
+<!-- end expires 2026-11-02 -->
+
+### Available rules
+
+* **Actor rules** control who can trigger workflows, including individual users, repository roles, {% data variables.product.prodname_github_apps %}, {% data variables.product.prodname_copilot_short %}, and {% data variables.product.prodname_dependabot %}. 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.
+* **Event rules** control which events are permitted, such as `push`, `pull_request`, `pull_request_target`, and `workflow_dispatch`.
+
+{% data variables.product.github %} plans to add more rules over time.
+
+## Next steps
+
+To configure workflow execution protections, see [AUTOTITLE](/actions/how-tos/administer/control-workflow-execution).
+
+To manage policies programmatically, see [AUTOTITLE](/rest/actions/policies).

content/actions/concepts/index.md

@@ -12,6 +12,7 @@ children:
   - /security
   - /metrics
   - /billing-and-usage
+  - /about-actions-policies
 redirect_from:
   - /actions/concepts/use-cases
 contentType: concepts

content/actions/how-tos/administer/control-workflow-execution.md

@@ -0,0 +1,85 @@
+---
+title: Controlling who can execute {% data variables.product.prodname_actions %} workflows
+shortTitle: Control workflow execution
+intro: Control who can trigger {% data variables.product.prodname_actions %} workflows and which events are permitted to run them across an enterprise, organization, and repository.
+versions:
+  feature: workflow-execution-protections
+contentType: how-tos
+redirect_from:
+  - /repositories/managing-your-repositorys-settings-and-features/actions-policies/workflow-execution-protections
+  - /organizations/managing-organization-settings/actions-policies/workflow-execution-protections
+  - /admin/enforcing-policies/enforcing-policies-for-your-enterprise/actions-policies/workflow-execution-protections
+permissions: 'Repository administrators, organization owners, and enterprise owners'
+product: 'All public repositories, and private repositories on {% data variables.product.prodname_team %} or {% data variables.product.prodname_enterprise %}.'
+---
+
+{% data reusables.actions.actions-policies-about-body %} For more information, see [AUTOTITLE](/actions/concepts/about-actions-policies).
+
+<!-- expires 2026-11-02 -->
+
+{% ifversion default-pull-req-target-policy %}
+
+> [!NOTE] {% data reusables.actions.workflows.pull-request-target-policy %}
+
+{% endif %}
+
+<!-- end expires 2026-11-02 -->
+
+## 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.
+
+   * Deployment status comes from an organization's {% data variables.product.virtual_registry %}. If this is an important factor, make sure you're uploading deployment records when an artifact is deployed. See [AUTOTITLE](/code-security/concepts/supply-chain-security/linked-artifacts).
+   * To create and assign custom properties, see [AUTOTITLE](/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization).
+
+1. **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.
+1. **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 [AUTOTITLE](/organizations/organizing-members-into-teams/creating-a-team) or [AUTOTITLE](/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams).
+
+## 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.
+1. In the left sidebar, under **Actions**, click **Policies**.
+
+In an enterprise:
+
+1. Click the **{% octicon "law" aria-hidden="true" aria-label="law" %} Policies** tab.
+1. In the left sidebar, click **Actions**, then **Policies**.
+
+> [!TIP] To manage policies programmatically, see [AUTOTITLE](/rest/actions/policies).
+
+### Configuring the policy
+
+Next, create a new policy.
+
+1. Choose a name for the policy.
+1. Choose an enforcement status. If you select **Evaluate** ({% data variables.product.prodname_ghe_cloud %} only), you will be able to monitor when users would hit the restriction in policy insights.
+1. Target your desired workflows, organizations, or repositories.
+1. 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.
+
+{% data variables.product.github %} features are exempt from these restrictions for the built-in processes that they run on {% data variables.product.prodname_actions %}. However, if you have created workflows that need to be run by the identity associated with a {% data variables.product.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 {% data variables.product.prodname_actions %} policies in your repository, organization, or enterprise sidebar.

content/actions/how-tos/administer/index.md

@@ -7,6 +7,7 @@ versions:
   ghes: '*'
   ghec: '*'
 children:
+  - /control-workflow-execution
   - /view-metrics
   - /reuse-namespaces-on-ghecom
 redirect_from:

content/actions/reference/limits.md

@@ -26,17 +26,32 @@ These limits are subject to change.
 
 | Limit category | Limit | Threshold | Description | Can {% data variables.product.github %} Support increase? |
 | :---- | :---- | :---- | :---- | :---- |
+| {% ifversion fpt or ghec %} |
+| Workflows queuing | Webhook events received (Free) | 100 events / 10 seconds / repository | Each repository is limited to incoming webhook events, whether or not they match a workflow trigger. If this front-door limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Webhook events received (Pro) | 500 events / 10 seconds / repository | Each repository is limited to incoming webhook events, whether or not they match a workflow trigger. If this front-door limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Webhook events received (Team) | 500 events / 10 seconds / repository | Each repository is limited to incoming webhook events, whether or not they match a workflow trigger. If this front-door limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Webhook events received (Legacy paid plans) | 500 events / 10 seconds / repository | Each repository is limited to incoming webhook events, whether or not they match a workflow trigger. If this front-door limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Webhook events received (Enterprise) | 1,500 events / 10 seconds / repository | Each repository is limited to incoming webhook events, whether or not they match a workflow trigger. If this front-door limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Free, public repository) | 20 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Free, private repository) | 10 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Pro) | 200 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Team) | 200 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Legacy paid plans) | 200 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Events eligible to trigger workflows (Enterprise) | 400 events / 10 seconds / repository | Each repository is limited to events that match any workflow. If this limit is exceeded, subsequent events are rejected until the event rate falls below the limit. | {% octicon "x" aria-label="No" %} |
+| Workflows queuing | Workflow runs queued | 500 workflow runs / 10 seconds / repository | Each repository is limited to workflow runs queued. One eligible event can create multiple workflow runs, while a run with reusable workflows counts as one workflow run. When the limit is reached, additional workflow runs are blocked and will not be queued. | {% octicon "x" aria-label="No" %} |
+| {% else %} |
+| Workflows queuing | Webhook event limit | 1500 events / 10 seconds / repository | This limit controls the number of webhook events that a repository can receive within a 10-second period. Not every webhook event triggers a workflow run. | {% octicon "check" aria-label="Yes" %} Support ticket |
+| Workflows queuing | Workflow run queued | 500 workflow runs / 10 seconds | When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued. Reusable workflows are viewed as a single entity. For example, a run with 30 reusable workflows counts as 1 in this instance. | {% octicon "x" aria-label="No" %} |
+| {% endif %} |
+| {% ifversion actions-nga %} |
+| Workflows queuing | Concurrency group queue | 100 workflow runs / concurrency group | When using `queue: max` in the `concurrency` section, up to 100 jobs or workflow runs can be queued per concurrency group. Runs beyond this limit will be rejected. | {% octicon "x" aria-label="No" %} |
+| {% endif %} |
 | Workflow execution limit | Workflow run time | 35 days / workflow run | If a workflow run reaches this limit, the workflow run is cancelled. This period includes execution duration, and time spent on waiting and approval. | {% octicon "x" aria-label="No" %} |
 | Workflow execution limit | Gate approval time | 30 days | A workflow may wait for up to [30 days on environment approvals](/actions/reference/workflows-and-actions/deployments-and-environments#wait-timer). | {% octicon "x" aria-label="No" %} |
 | Workflow execution limit | Job Matrix | 256 jobs / workflow run | A job matrix can generate a maximum of 256 jobs per workflow run. This limit applies to both {% data variables.product.github %}-hosted and self-hosted runners. | {% octicon "x" aria-label="No" %} |
 | Workflow execution limit | Re-run | 50 re-runs | A workflow run can be re-run a maximum of 50 times. This limit includes both full re-runs and re-runs of a subset of jobs. | {% octicon "check" aria-label="Yes" %} Support ticket |
 | Workflow file | Workflow file size | 500 KB per file | A workflow file larger than 500 KB will not start runs. See [Workflow file size](#workflow-file-size). | {% octicon "x" aria-label="No" %} |
 | Checks | Check runs per check suite | 50,000 check runs / check suite | A check suite can have a maximum of 50,000 check runs. This limit applies to check runs created through the Checks API and by {% data variables.product.prodname_actions %} workflow runs. When a check suite reaches this limit, additional check runs cannot be created for that check suite. | {% octicon "check" aria-label="Yes" %} Support ticket |
-| Workflows queuing | Workflow trigger event rate limit | 1500 events / 10 seconds / repository | Each repository is limited to events triggering a workflow run. | {% octicon "check" aria-label="Yes" %} Support ticket |
-| Workflows queuing | Workflow run queued | 500 workflow runs / 10 seconds | When the limit is reached, the workflow runs that were supposed to be triggered by the webhook events will be blocked and will not be queued. Reusable workflows are viewed as a single entity. For example, a run with 30 reusable workflows counts as 1 in this instance. | {% octicon "x" aria-label="No" %} |
-| {% ifversion actions-nga %} |
-| Workflows queuing | Concurrency group queue | 100 workflow runs / concurrency group | When using `queue: max` in the `concurrency` section, up to 100 jobs or workflow runs can be queued per concurrency group. Runs beyond this limit will be rejected. | {% octicon "x" aria-label="No" %} |
-| {% endif %} |
 | Self-hosted | Runner registrations | 1500 runners / 5 minutes / repository/org/enterprise | Runners can be registered per repository/organization/enterprise. | {% octicon "check" aria-label="Yes" %} Support ticket |
 | Self-hosted | Runners per runner group | 10,000 runners | Runners registered at the same time per runner group. | {% octicon "x" aria-label="No" %} |
 | Self-hosted | Job execution time | 5 days | Each job in a workflow can run for up to 5 days of execution time. If a job reaches this limit, the job is terminated and fails. | {% octicon "x" aria-label="No" %} |