GitHub Actions Execution Protections: A Security Guide

A GitHub Actions workflow can be valid YAML and still be an unsafe program. The dangerous part is often the boundary between an untrusted pull request and a trusted runner with repository credentials. A single trigger choice can let code from a fork execute with a write-capable token, organization secrets, or access to an internal network.

GitHub's workflow execution protections give administrators a control before the runner starts. The policy can restrict the actors allowed to trigger a workflow, the events allowed to start it, and the workflow files covered by the rule. GitHub made these protections generally available on September 17, 2026, with management at enterprise, organization, and repository scope.

That does not make every Actions workflow safe. It does give platform teams a useful enforcement layer for rules that were previously scattered across YAML reviews, repository templates, and tribal knowledge.

What Workflow Execution Protections Control

Execution protections answer two questions before GitHub accepts a run:

1. Is this actor allowed to trigger the workflow?
2. Is this event allowed to start it?

Actor rules cover the person or integration behind an event. Event rules cover triggers such as push, pull_request, workflow_dispatch, and pull_request_target. Both conditions must pass when both types of rule apply.

GitHub's general availability announcement added workflow-file targeting, policy insights, and a REST API. This matters because repositories rarely have one risk level. A lint workflow can run for every contributor, while a production deployment should have a narrower entry point.

Policy Scope Is Separate From Workflow Permissions

An execution policy controls whether a run starts. The YAML file still controls jobs, token permissions, environments, and commands after that point. Think of the policy as the lock on the workshop door. It does not make every tool inside harmless.

This distinction prevents a common implementation mistake: enabling a policy and then leaving permissions: write-all, long-lived cloud credentials, or reusable self-hosted runners unchanged.

Why pull_request_target Needs Special Attention

The pull_request_target event exists for legitimate automation around pull requests from forks. It runs the workflow definition from the base repository's default branch, which means trusted workflow code can label a pull request, post a comment, or run another authenticated administrative task.

It also runs with the base repository's trust. According to GitHub's security guide for pull_request_target, the job can receive the base repository's GITHUB_TOKEN and configured secrets. Trouble starts when the workflow checks out code from the pull request and then executes it.

# Unsafe example. Do not copy this into a repository.
on:
  pull_request_target:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm install
      - run: npm test

The workflow file is trusted, but the checked-out package.json, lifecycle scripts, build configuration, and tests are controlled by the pull request author. npm install is enough to run attacker-controlled code. The attacker does not need to edit the workflow YAML.

GitHub and security researchers call this pattern a "pwn request." The same class of error can appear in a workflow_run or issue_comment workflow that downloads a pull-request artifact and treats it as executable code.

The New Default Policy for Public Repositories

GitHub is introducing a default event policy that disables pull_request_target for public repositories without an existing applicable event policy. The rule initially runs in evaluate mode. GitHub plans to enforce it on November 2, 2026 for affected repositories that were using the default policy before general availability.

Private and internal repositories are not included in that automatic default. They can still contain unsafe privileged workflows, especially when outside collaborators, compromised accounts, or automated dependencies can influence inputs. Platform teams should inventory those repositories instead of assuming privacy is a security boundary.

The staged rollout is sensible. Immediately disabling every use of pull_request_target would break legitimate triage and reporting automation. Evaluate mode shows the blast radius first.

Start With an Inventory, Not a New Rule

Search the organization for privileged triggers and follow their data flow. Finding the event name is only the first step.

rg -n "pull_request_target|workflow_run|issue_comment" \
  --glob '.github/workflows/*.{yml,yaml}'

For each match, answer four questions:

• Does the job receive secrets or a write-capable token?
• Does it fetch a pull-request branch, commit, artifact, or user-controlled repository?
• Does any later step execute or source that content?
• Does the runner have access to internal services that are not represented in the YAML?

The last question matters on self-hosted runners. A token with read-only repository permissions can still be dangerous if the machine can reach a deployment controller, package-signing service, or production database.

GitHub's broader secure use reference recommends avoiding privileged triggers unless they are necessary, using least-privilege credentials, and keeping untrusted code away from privileged contexts.

Separate Untrusted Testing From Trusted Follow-Up Work

Most pull-request CI does not need secrets. Use pull_request for compilation, unit tests, linting, and other work that executes contributor code. GitHub limits the token and withholds repository secrets for forked pull requests.

name: Pull request checks

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-26.04
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v5
        with:
          node-version: 24
          cache: npm
      - run: npm ci --ignore-scripts
      - run: npm test

If a later task needs credentials, pass a narrow result across the trust boundary. A privileged workflow can read a test verdict or a deliberately constrained artifact without running the contributor's scripts. Treat the artifact as untrusted input and validate its format.

For administrative pull-request automation, keep pull_request_target but avoid checking out the pull-request head. Labeling and commenting generally require metadata, not contributor code.

Target Policies to the Workflow That Carries Risk

Workflow-file targeting avoids an organization-wide choice between blocking too much and permitting too much. A repository can allow routine CI while restricting .github/workflows/deploy.yml or any file matching a release pattern.

Conceptually, the policy can express a rule like this:

{
  "name": "Restrict production workflow actors",
  "enforcement": "evaluate",
  "conditions": {
    "workflow_path": {
      "include": [".github/workflows/deploy.yml"],
      "exclude": []
    }
  },
  "rules": [
    {
      "type": "restrict_actions_actors",
      "parameters": {
        "allowed_actors": [
          { "id": 123456 }
        ]
      }
    }
  ]
}

Use the exact schema from GitHub's Actions policies REST API for your scope and API version. Actor IDs and rule shapes should come from the API, not a copied example.

Workflow paths also make exceptions visible. An exception for one labeling workflow is easier to review than a repository-wide permission for every pull_request_target event.

Understand Policy Inheritance Before Adding Exceptions

Actions policies can exist at enterprise, organization, and repository scope. A repository owner may see one local rule while a broader rule also affects the run. Before changing an exception, identify the source of every applicable policy and which level owns the decision.

An enterprise baseline should cover rules that are genuinely universal, such as preventing unknown actors from starting sensitive release workflows. Organization rules can express the needs of a business unit or repository class. Repository rules should remain narrow and documented.

Avoid copying the same rule into hundreds of repositories. Duplicated policy drifts, and an emergency change becomes a large synchronization job. Apply a higher-level baseline where possible, then use repository properties or explicit repository conditions to group exceptions.

The Actions policy API supports conditions based on repository names, repository IDs, or repository properties at supported scopes. Custom properties are useful for declaring intent such as data-classification=restricted or deployment-tier=production. A policy can then follow the repository's declared role instead of a manually maintained name list.

Treat those properties as governed configuration. If any repository administrator can change the property that decides whether a deployment policy applies, the policy boundary has moved to the property editor.

Use a Two-Workflow Pattern for Privilege Separation

Some CI jobs must test untrusted code and later publish an authenticated result. Combining both jobs under a privileged trigger creates an avoidable conflict. Split the work by trust level.

The first workflow runs on pull_request, receives a read-only token, and has no repository secrets. It executes tests and writes a small result artifact. The second workflow runs in a trusted context after the first completes. It validates the artifact as data and performs only the narrow authenticated action.

name: Untrusted tests

on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-26.04
    steps:
      - uses: actions/checkout@v6
      - run: ./scripts/test.sh
      - name: Write result
        if: always()
        run: jq -n --arg conclusion "${{ job.status }}" \
          '{schema: 1, conclusion: $conclusion}' > result.json
      - uses: actions/upload-artifact@v5
        with:
          name: test-result
          path: result.json

The privileged follow-up should download only the expected artifact, reject unexpected files, validate the schema, and avoid executing any content from it.

name: Publish trusted check

on:
  workflow_run:
    workflows: ["Untrusted tests"]
    types: [completed]

permissions:
  contents: read
  checks: write

jobs:
  publish:
    runs-on: ubuntu-26.04
    steps:
      - name: Download and validate result
        run: |
          # Fetch the artifact for the specific workflow_run ID.
          # Validate JSON fields before using them in an API request.
          # Never source the file or execute a script from the artifact.
          true

This is not a copy-ready second workflow because artifact retrieval needs repository-specific API handling and pull-request identification. The important design is the boundary: untrusted code produces constrained data, and trusted code validates that data before acting.

workflow_run is still privileged. Downloading a shell script from the first job and running it recreates the original vulnerability with an extra workflow in between.

Review Reusable Workflows and Composite Actions

A visible workflow may delegate most of its behavior to a reusable workflow or composite action. The trigger policy applies to the entry workflow, while the delegated code determines which permissions and inputs reach later steps.

Inventory calls that use workflow_call, local paths under .github/actions, and remote uses: references. Confirm that reusable workflows declare explicit input types and secrets, and that callers do not pass all secrets by inheritance without a reason.

Pin remote reusable workflows to a full commit SHA when the trust level demands it. A tag such as @v3 is readable, but the tag owner can move it. Keep a comment with the human-readable version beside the SHA, then use dependency automation to propose reviewed updates.

Composite actions deserve the same input review as inline shell. An input interpolated directly into run: can become a script injection even when the caller's YAML looks tidy.

Test the Policy and the Workflow Together

A policy test should cover allowed and denied cases. Create a small matrix for each sensitive workflow:

Case	Expected Result
Approved maintainer starts workflow_dispatch	Run starts
Outside contributor opens a fork pull request	Untrusted CI starts with no secrets
Fork pull request triggers privileged deployment workflow	Run is blocked
Approved release bot triggers tagged release	Run starts
Unapproved actor retries failed production job	Run is blocked

Test the workflow after it starts as well. Confirm effective token permissions, accessible secrets, environment approval behavior, runner network access, and the exact ref checked out. A policy can pass perfectly while the job executes the wrong commit.

Keep a canary repository for policy changes that could affect many teams. Apply the proposed rule there, observe evaluate-mode results, and run controlled events before widening the condition. This catches path patterns and actor IDs that looked correct in a configuration review but behave differently in the platform.

Use Evaluate Mode as a Deployment Phase

A security policy deployed without evidence often produces one of two outcomes: it breaks delivery, or administrators weaken it until nobody complains. Evaluate mode offers a better route.

Run the policy in shadow mode for a representative period. Review which actors, events, repositories, and workflow paths would have been blocked. Classify every match:

• Expected violation that should stop after enforcement
• Legitimate workflow that needs a narrow exception
• Obsolete workflow that should be deleted
• Unexpected path or actor that needs investigation

Do not measure success by the number of rules created. Measure the number of privileged paths that now have an owner, a reason to exist, and a testable boundary.

Policy insights are available to enterprise administrators. Smaller teams without evaluate mode can approximate the exercise by querying workflow files and recent runs before applying repository rules.

Manage Execution Policy as Code

The REST API supports create, read, update, and delete operations for policies at supported enterprise, organization, and repository scopes. That allows a platform team to define a baseline, apply it consistently, and detect drift.

A safe policy pipeline should have the same qualities as application delivery:

1. Store the desired policy in version control.
2. Validate the document against a schema.
3. Produce a readable diff before applying it.
4. Start material changes in evaluate mode.
5. Require review for new exceptions.
6. Record the policy ID and API response after deployment.

Avoid a script that blindly replaces every policy on every run. Enterprise, organization, and repository rules can overlap. The deployment logic should understand precedence and preserve intentional exceptions.

Token Permissions Still Need Their Own Review

Every workflow should declare the smallest useful GITHUB_TOKEN permission set. A read-only default is easier to reason about than inherited write access.

permissions:
  contents: read

jobs:
  publish-report:
    permissions:
      contents: read
      checks: write

Use environment protection and required reviewers for jobs that need deployment secrets. Prefer short-lived identity federation through OpenID Connect over static cloud keys when the provider supports it. For external automation, a GitHub App with narrow permissions and short-lived installation tokens is usually safer than a personal access token tied to one employee.

GitHub's secrets documentation also warns that log redaction is not guaranteed for every transformed secret. Prevent exposure at the permission boundary instead of relying on masking after a value reaches the runner.

Treat Inputs, Actions, Caches, and Runners as Code

Execution protections cover triggers. Several other paths remain.

Untrusted Context Values

Pull-request titles, branch names, issue bodies, labels, and commit messages can carry shell syntax. GitHub's script injection guidance recommends keeping those values out of inline scripts. Pass data through an environment variable and quote it correctly, or use an action whose API treats the value as data.

Third-Party Actions

Pin sensitive third-party actions to a full commit SHA. A floating tag can change after review. Dependabot can help maintain the pinned reference without quietly trusting the next tag target.

Caches

Privileged workflows can consume poisoned build caches if trust levels share a writable cache scope. GitHub now restricts cache writes for pull_request_target by default. Opting into a write-capable cache mode restores the risk that the protection was designed to remove.

Self-Hosted Runners

Do not reuse a mutable runner for untrusted code unless the environment is strongly isolated and reset between jobs. Ephemeral runners with a restricted network reduce the chance that one pull request leaves credentials, processes, or modified tools for the next job.

A Practical Rollout Plan

Start with the workflows that can write code, publish packages, deploy software, or reach production systems.

During the first week, inventory privileged triggers and declare token permissions. In the second, separate untrusted testing from authenticated follow-up work. Then create targeted event and actor policies in evaluate mode. Review the insights with repository owners before enforcement.

Document every exception with a workflow path, business purpose, owner, and expiry or review date. Scan Actions YAML with CodeQL where available. Add a repository rule or CI check that rejects new privileged workflows without a security review.

Track a few operating metrics after enforcement: blocked runs by rule, exception count, exceptions past review date, privileged workflows without explicit permissions, and repositories using self-hosted runners for forked pull requests. A sudden rise in blocked runs may show an attack, a broken developer workflow, or a policy condition that is too broad. The investigation should distinguish them.

Review policies whenever a workflow gains a new trigger, secret, environment, or runner class. A labeling workflow can become a deployment workflow gradually, one convenient step at a time. Its old exception should not silently follow it into the new risk level.

The useful outcome is not a green policy dashboard. It is a CI system where an untrusted contribution can be tested without inheriting the authority to alter the repository that is testing it.

---