Runner policy is the set of rules that determines which execution environments a CI/CD job may use. Strong policy limits where workflows run, which labels they can request, and whether unreviewed automation can reach sensitive secrets or network paths.
What Runner Policy Controls
Runner policy defines the guardrails for CI/CD execution, deciding which runners a job can land on, what labels it may request, and whether automation is allowed onto environments that can reach secrets, build credentials, or internal networks.
Why Runner Policy Matters
Runner placement is not just an operational detail, it is part of the trust boundary for pipeline execution. A permissive policy can let unreviewed jobs run on privileged hosts, while a restrictive policy can force sensitive workflows onto tightly controlled environments with better isolation.
Because runner choice affects where code executes, it also affects what that code can reach. If policy is weak, a routine build can become a path to secret exposure, lateral movement, or unauthorized network access.
Common Runner Policy Patterns
Most runner policies combine three ideas: scope, labels, and trust level. Scope limits which projects or workflows can use a runner, labels constrain the classes of jobs that may request it, and trust level separates routine automation from workflows that handle protected data or deployment actions.
In practice, teams often distinguish between shared runners, dedicated runners, and protected runners. Shared runners are convenient for low-risk work, dedicated runners reduce cross-project exposure, and protected runners are reserved for jobs that need stronger review, network segmentation, or secret access controls.
Runner Policy and Security Boundaries
Runner policy is closely tied to secret handling, artifact integrity, and environment isolation. A job that can choose an overly capable runner may inherit access to credentials, internal services, or cached state that was meant for a narrower trust zone.
It also shapes blast radius. If an attacker can influence workflow configuration, runner selection becomes part of the abuse path, because the policy determines whether that workflow can reach sensitive build steps or privileged infrastructure.
Risk and Threat Considerations
Weak runner policy can turn CI/CD into an access escalation path. The main risk is not the runner itself, but the combination of untrusted automation, overbroad labels, and environments that can reach secrets or internal networks.
Failure mechanism: A workflow is allowed onto a runner with more privilege, broader network reach, or persisted credentials than the job legitimately needs, which lets malicious or compromised build logic extract secrets, tamper with artifacts, or pivot into adjacent systems.
Impact: The result can be source compromise, release tampering, secret leakage, and wider environment exposure, especially when runner assignment is controlled only by convention rather than enforceable policy.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Covers excessive execution privilege that lets automation reach secrets or sensitive paths |
| NHI-08 — Environment Isolation | Covers separating execution environments to prevent cross-workload exposure | |
| Recommendation — Restrict runner access so jobs receive only the privileges and reach they need. Segregate sensitive runners from shared execution environments and network zones. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Directly supports limiting what runner-selected jobs can access or do |
| SC-7 — Boundary Protection | Applies where runner policy controls network paths into sensitive systems | |
| IA-5 — Authenticator Management | Relevant when runner policy governs use and protection of job credentials | |
| Recommendation — Apply least privilege to runner access, labels, and reachable resources. Enforce network boundaries so runners cannot reach sensitive services by default. Protect and rotate credentials exposed to runners according to their trust level. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Supports managing who and what may use privileged execution environments |
| CIS-8 — Audit Log Management | Helps detect unauthorized runner selection and suspicious pipeline execution | |
| Recommendation — Tighten access to runners and remove unneeded execution paths promptly. Log runner assignment and review unusual job placement patterns. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Credential Management | Applies because runner policy governs credential-bearing automation access |
| Recommendation — Bind runner access to managed credentials and enforce approval for sensitive jobs. | ||
Practitioner Guidance
Governance implication: Treat runner selection as an authorization decision, not a convenience setting. The policy should express which classes of jobs may use which execution environments, and sensitive workflows should be forced onto runners with the smallest practical privilege and the narrowest network path.
What to watch for: Review any label or selector that can be self-assigned by untrusted jobs, any runner that can reach secrets by default, and any shared environment that mixes low-trust and high-trust workloads. Those are the places where policy drift most often creates hidden exposure.