A workflow run policy is a pre-execution governance control that evaluates a GitHub Actions run before code executes. It can block or cancel runs that violate security rules, such as use of compromised actions, mutable references, or disallowed workflow patterns, reducing the chance of secret exposure.
Expanded Definition
A workflow run policy is a pre-execution governance control for CI/CD systems, most notably GitHub Actions, that inspects a run before code is allowed to execute. It is designed to stop risky or noncompliant workflows from reaching runtime, especially where untrusted actions, mutable references, or unsafe pattern combinations could expose secrets or escalate access.
In NHI security, the control matters because workflow runs often operate with service account tokens, repository secrets, cloud credentials, and deployment permissions. A run policy does not replace least privilege, secret rotation, or approval workflows. Instead, it adds a gate that evaluates whether the requested execution context is acceptable before any NHI-bearing automation is activated. Guidance varies across vendors, and no single standard governs this yet, so implementations differ in what they inspect and how they enforce blocking. For a governance baseline, practitioners often map this control to broader policy enforcement expectations described in the NIST Cybersecurity Framework 2.0.
The most common misapplication is treating workflow run policy as a substitute for repository hardening, which occurs when teams assume pre-execution checks alone can neutralise compromised actions or leaked secrets.
Examples and Use Cases
Implementing workflow run policy rigorously often introduces build friction, requiring organisations to weigh release speed against the cost of blocking risky automation before it starts.
- Blocking a GitHub Actions run that references a compromised third-party action, preventing the workflow from loading attacker-controlled code.
- Rejecting a run that uses a mutable branch reference instead of a pinned commit SHA, reducing the chance of silent supply chain drift.
- Stopping a deployment workflow when the requested job would access high-value secrets without the approved environment conditions or reviewers.
- Disallowing workflows that combine self-hosted runners, broad token permissions, and untrusted pull-request triggers in the same execution path.
- Using policy checks to prevent a rerun of an old workflow snapshot after a known action compromise, as discussed in NHIMG coverage of the GitHub Action tj-actions Supply Chain Attack and the broader Top 10 NHI Issues.
Because definitions vary across vendors, some tools focus only on action provenance while others also inspect token scope, branch protection, and runner trust boundaries. In practice, the strongest use cases are those that treat workflow admission as a security decision, not just a developer convenience feature.
Why It Matters in NHI Security
Workflow run policy is important because CI/CD pipelines are a high-risk junction where machine identities, secrets, and execution authority converge. If a workflow is allowed to start with a compromised action or overly permissive token, the result can be silent secret exposure, unauthorized deployment, or lateral movement into cloud and production systems. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and CI/CD automation is one of the most exposed places where those identities are used.
This is why pre-execution control belongs in NHI governance, not just DevOps hygiene. It supports a Zero Trust posture by assuming workflow inputs can be hostile until validated. It also complements the lifecycle controls described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the governance lens in Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The key lesson is that execution policy only becomes urgent when trust has already been abused. Organisations typically encounter repeated secret leakage or unexpected repository compromise only after a workflow has run with unsafe permissions, at which point workflow run policy becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses unsafe secret handling and workflow-triggered exposure paths. |
| OWASP Agentic AI Top 10 | A-04 | Covers tool execution governance before autonomous actions are allowed. |
| NIST CSF 2.0 | PR.AC-3 | Maps to access enforcement for systems and workflows before use. |
| NIST Zero Trust (SP 800-207) | Pre-execution verification aligns with Zero Trust decision points. | |
| NIST AI RMF | Supports governance and measurement of automated system risk decisions. |
Treat each workflow run as untrusted until its identity, context, and permissions are verified.
Related resources from NHI Mgmt Group
- When should organisations move from local workflow review to platform-level policy?
- How should teams design policy-based access reviews without creating workflow sprawl?
- Who is accountable when a workflow can change authorization policy?
- Who should own authorization policy for workflow systems: IAM, app teams, or platform teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
