# Policies
Use this page to view and manage all workflow run policies created in your organization.
## Creating a New Policy in Your Organization
There are five policy types you can create:
* [Compromised Actions Policy](#compromised-actions-policy) - Block the use of compromised Actions
* [Secret Exfiltration Policy ](#secret-exfiltration-policy)- Prevents unauthorized access to Secrets
* [Allowed Actions Policy ](#allowed-actions-policy)- Block specific GitHub Actions
* [Runner Label Policy](#runner-label-policy) - Prevent or monitor usage of specific runners
* [Harden-Runner Policy](#harden-runner-policy) - Require the Harden-Runner action in every workflow run
### Compromised Actions Policy
The Compromised Actions Policy prevents the use of known malicious or compromised GitHub Actions in workflows. It scans for references to actions flagged as security risks and blocks their execution to protect your environment.
#### **Why It Matters**
Workflows often rely on third-party actions, which may be:
* Compromised via account takeovers
* Malicious by design
* Altered to include malware or backdoors
This policy reduces risk by:
* Maintaining a list of compromised actions
* Scanning workflows for those references
* Blocking runs using them
* Alerting developers with actionable feedback
**What Developers See**
If a compromised action is used:
* The workflow is automatically canceled and a PR comment explains the violation and suggests trusted alternatives
To try the Compromised Action policy, add this action to your workflow:
```
step-security/dummy-compromised-action@main
```
**To create a compromised Actions policy, follow the steps below:**
**Step 1: Navigate to the Workflow Run Policies page**
* Go to your StepSecurity dashboard, then to Workflow Run Policies → Policies in the sidebar.
**Step 2: Click “Create Policy”**
* Click the Create Policy button on the top right of the page.
Click the create button
**Step 3: Fill in Policy Details**
* Policy Name – e.g., *Compromised Actions Policy*
* Policy Type – Select "Compromised Actions Policy"
* Action – Choose between:
* Enforce: Actively blocks compromised Actions
* Dry Run: Does not block the workflow run but records the violation in the Evaluations page
Setting up Compromised Actions Policy
**Step 4: Select Repositories/Organizations**
* Choose whether to apply the policy to:
* All current and future repositories/organizations *(default)*, or
* Select specific repositories/organizations manually
**Step 5: Save the Policy**
* After configuring all settings, click Save to create the policy.
Follow this interactive demo to see how this workflow run policy works in practice:
{% embed url="" %}
### Secret Exfiltration Policy
The Secret Exfiltration Policy protects against unauthorized secret access in GitHub Actions. It blocks modified workflows in non-default branches from using secrets unless explicitly approved.
#### **Why It Matters**
Workflows often need secrets to access protected resources. Attackers may exploit non-default branches to run malicious workflows and exfiltrate secrets. This policy helps stop that by:
* Allowing secret access only if the workflow matches the default branch
* Enforcing approval for legitimate changes
* Creating an auditable approval trail
**How It Works**
* Detects non-default branch workflows accessing secrets (${{ secrets.X }}, toJSON(secrets))
* Compares workflow content to the default branch using SHA256
* Requires a workflows-approved label from a different team member for approval
* Blocks runs without proper matching or approval
**What Developers See**
If a modified workflow accesses secrets:
* The run is canceled, and a PR comment explains the block and how to get approval (a teammate has to add the "**workflows-approved**" label to the PR)
* Once the "workflows-approved" label has been added by a teammate, the workflow can be re-run
#### Creating a **Secret Exfiltration** Policy
**Step 1: Select “Secret Exfiltration Policy”**
* You can exempt specific users or bot accounts from this policy. When a workflow is triggered by an exempted user or bot, the run will not be blocked by the policy.
**Step 2: Choose Target Repositories/Organizations**
**Step 3: Save the Policy**
Follow this interactive demo to see how this workflow run policy works in practice:
{% embed url="" %}
### Allowed Actions Policy
Use this policy to enforce an allowlist of GitHub Actions. Any action not on the allowlist is blocked (Enforce) or flagged (Dry Run). You can also require that every allowed action be pinned to a specific commit SHA, which protects against tag-overwrite and supply-chain attacks.
#### Why It Matters
Every third-party GitHub Action that runs in your workflow inherits access to your repository's `GITHUB_TOKEN` and any secrets the job exposes. An unvetted, typosquatted, or compromised action can:
* Exfiltrate secrets, tokens, or source code
* Inject malicious code into build artifacts
* Pivot into internal systems via repository-scoped credentials
* Execute arbitrary commands with the permissions of the workflow
Maintaining an allowlist narrows your exposure to the set of actions your security team has reviewed. Requiring pinned references on top of that protects you from a second category of attack: a previously-trusted action whose `@v4` tag or `@main` branch is moved to point at malicious code — the pattern behind the `tj-actions/changed-files` compromise and similar incidents.
#### Creating an **Allowed Actions** Policy
**Step 1: Select “Allowed Actions Policy”**
**Step 2: (Optional) Require pinned actions**
Toggle **Only allow pinned actions** on if you want to block any action reference that is not pinned to a commit SHA. This applies on top of the allowlist — an action must be both allowlisted and pinned to pass.
**Step 3: Add Actions to Allowlist**
* Manually type and add actions (e.g., `actions/checkout`) **OR**
* Use All Actions (Used) to select from known usage
* Select one Action and click "Add to Allowed List"
* Decide whether to allow all versions (default) or select specific commit versions **OR**
* **Use Repository Filter (Optional):** Go to **By Repository (Used)** tab → Select a repo → Add used actions
**Step 4: Click "Save"**
Follow this interactive demo to see how this workflow run policy works in practice:
{% embed url="" %}
### Runner Label Policy
Use this policy to block untrusted GitHub-hosted runners or allow only specific self-hosted runners.
#### Why It Matters
The `runs-on` value determines what machine a job actually executes on, and different runner labels have very different security and cost profiles.
The Runner Label Policy lets you enforce that jobs only execute on approved runner labels. This is useful when you want to block specific runner types, for example, preventing the use of GitHub-hosted runners because your organization standardizes on self-hosted runners for security or compliance reasons.
#### Creating a Runner Label Policy
**Step 1: Fill in Policy Details**
* Policy Name – e.g., *Do not allow GitHub-Hosted Runners*
* Policy Type – Select Runner Label Policy
* Action – Choose between:
* Enforce: Actively blocks disallowed runner labels
* Dry Run: Does not block the workflow run but records the violation in the Evaluations page
**Step 2: Specify Disallowed Runner Labels**
* Type in the runner labels you want to block (e.g., ubuntu-latest, macos-latest) and press Enter to add.
**Step 3: Select Repositories/Organizations**
Choose whether to apply the policy to:
* All current and future repositories/organizations *(default)*, or
* Select specific repositories/organizations manually
Select Repositories
**Step 4: Save the Policy**
* After configuring all settings, click Save to create the policy.
Follow this interactive demo to see how this workflow run policy works in practice:
{% embed url="" %}
### Harden-Runner Policy
The Harden-Runner Policy ensures that every workflow run in your organization executes in a hardened environment. It blocks jobs where the [Harden-Runner](https://github.com/step-security/harden-runner) action is missing, or where it is present but is not configured as the first step of the job.
#### Why It Matters
Harden-Runner provides runtime security for GitHub-hosted runners — network egress filtering, file integrity monitoring, process monitoring, and outbound call auditing. These protections only take effect if the action is initialized **before** any other step runs. A job that runs `actions/checkout` or installs dependencies before Harden-Runner has already given any malicious code an unmonitored window to execute.
This policy reduces risk by:
* Guaranteeing that Harden-Runner is adopted consistently across all covered repositories
* Preventing developers from accidentally (or intentionally) removing Harden-Runner from a workflow
* Ensuring Harden-Runner is always the first step, so no code executes before monitoring is active
* Supporting organization-specific bootstrap actions as valid Harden-Runner equivalents
#### Creating a Harden-Runner Policy
**Step 1: Fill in Policy Details**
* **Policy Name** — e.g., `Require Harden-Runner`
* **Policy Type** — select **Harden-Runner Policy**
* **Action** — choose between:
* **Enforce**: actively blocks jobs that are missing Harden-Runner or have it configured incorrectly
* **Dry Run**: does not block the workflow run but records the violation on the Evaluations page
**Step 2: (Optional) Scope the policy with Target runner labels**
By default the policy applies to **all jobs** across the selected repositories, including self-hosted runners that may not have the Harden-Runner action available.
To restrict the policy to specific runner types, toggle **Target runner labels** on and add one or more labels (for example, `ubuntu-latest`, `ubuntu-22.04`). The policy will then only evaluate jobs whose `runs-on` value matches one of these labels.
{% hint style="info" %}
Use this when you have a mix of GitHub-hosted and self-hosted runners and only want to enforce Harden-Runner on GitHub-hosted ones.
{% endhint %}
**Step 3: (Optional) Add Custom Actions**
If your organization wraps Harden-Runner inside an internal bootstrap action, add those actions under **Custom Actions** so they are recognized as valid Harden-Runner equivalents.
* Type the action's `owner/repo` (for example, `my-org/bootstrap-security`) and press **Enter** to add it.
* Version tags are ignored — matching is done on the action name only.
**Step 4: Select Repositories/Organizations**
Choose whether to apply the policy to:
* All current and future repositories/organizations *(default)*, or
* Specific repositories/organizations selected manually
**Step 5: Save the Policy**
**Follow this interactive demo to see how this workflow run policy works in practice:**
{% embed url="" %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.stepsecurity.io/workflow-run-policies/policies.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.