Reusable runners can retain tokens, cached dependencies, logs, and state from previous executions. That persistence creates a contamination risk because one compromised job may influence later jobs or leak material that should have been destroyed at the end of the build. Ephemeral runners reduce that blast radius by making each execution disposable.
Why This Matters for Security Teams
Reusable CI/CD runners are convenient, but convenience can hide a control failure. When the same worker handles multiple jobs, it can become a carrier for secrets, build artefacts, environment variables, cached packages, and even attacker-added tooling. That creates a path from one pipeline run into the next, especially when jobs differ in trust level or branch origin. NIST SP 800-53 Rev 5 Security and Privacy Controls NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames the need for isolation, least privilege, and controlled information flow.
The issue is not only secret leakage. Reuse can also preserve stale dependencies, modified configuration, local caches, and residual credentials that alter later job behaviour in ways that are hard to spot. In regulated environments, that can undermine auditability because the build result is no longer a clean output of a known pipeline state. Security teams often focus on the runner image and forget the execution boundary, which is where the real exposure sits. In practice, many security teams encounter runner contamination only after a downstream job inherits credentials or artefacts from an earlier compromised execution, rather than through intentional isolation testing.
How It Works in Practice
Ephemeral runners limit cross-job contamination by making each execution disposable. A job starts on a clean instance, receives only the secrets and permissions needed for that run, and is destroyed or scrubbed immediately afterward. By contrast, reusable runners depend on strong cleanup to avoid carrying state forward, and that cleanup is rarely perfect across every toolchain, cache layer, and plugin.
Operationally, the control question is whether the runner boundary is treated as trusted infrastructure or as a hostile reuse surface. Best practice is to separate jobs by risk level, restrict who can target shared runners, and keep sensitive pipelines on isolated workers. Where possible, secrets should be injected just in time and never written to disk. Build logs, caches, and workspace directories should be treated as data that can outlive the job unless they are explicitly destroyed.
- Use ephemeral or single-use runners for privileged, production, or release jobs.
- Segment self-hosted runners by repository, branch protection, or trust tier.
- Disable broad persistence for caches, workspaces, and package registries unless there is a clear risk review.
- Rotate and scope job tokens so a prior execution cannot meaningfully affect the next one.
- Monitor runner hosts for unexpected process persistence, outbound connections, and file residue.
For implementation detail, the zero trust lens is helpful because it assumes no execution context should be trusted simply because it ran before. The NIST Zero Trust Architecture guidance maps well to CI/CD worker design, while OWASP CI/CD Security Risks highlights how pipeline trust can be subverted through misconfiguration and secret exposure. These controls tend to break down when self-hosted runners are shared across teams with different privilege levels because cache reuse, filesystem residue, and inconsistent teardown become difficult to govern.
Common Variations and Edge Cases
Tighter runner isolation often increases operational overhead, requiring organisations to balance build speed and cost against secret exposure risk. There is no universal standard for runner reuse, so current guidance suggests matching the control to the sensitivity of the workflow rather than applying one model everywhere.
Some environments do accept reuse for low-risk jobs, such as public documentation builds or non-sensitive linting, but that decision should be explicit and bounded. The exception is when the same runner class handles both untrusted pull request builds and protected release jobs. That mixture creates a privilege boundary that is easy to miss and hard to audit after the fact. Caches can also be safe in one layer and dangerous in another, because dependency caching is useful while workspace persistence is not. Teams should distinguish between deterministic caches that are rebuilt from trusted sources and opaque state that may hold credentials or altered binaries.
This guidance becomes less reliable in highly dynamic fleet environments where runners are autoscaled, images are rebuilt frequently, and job scheduling is handled by multiple orchestrators. In those cases, cleanup assurance and identity of the runner itself become part of the security design. When supply chain integrity is in scope, the CISA Secure Software Development Framework is a useful companion reference because it reinforces hardened build processes, provenance, and controlled handoff between stages.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Runner reuse affects least privilege and access boundary enforcement. |
| MITRE ATT&CK | T1078 | Valid accounts abuse can persist across reused execution contexts. |
| OWASP Agentic AI Top 10 | Execution reuse mirrors agent tool and state persistence risks. |
Apply ephemeral execution and strict state reset wherever automated systems retain authority.
Related resources from NHI Mgmt Group
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
