Self-hosted runner persistence is the ability of a build or automation runner to remain available across jobs, restarts, or reboots. In security terms, it means the runner keeps state, credentials, files, or configuration that can survive task completion, creating a durable execution foothold that must be tightly controlled and monitored.
What Self-Hosted Runner Persistence Actually Means
Self-hosted runner persistence is the runner’s ability to stay present across jobs, reboots, or restarts while retaining state. That durability can be useful for performance and local caching, but it also means the runner can become a lasting control point if it is not isolated, reset, or monitored.
Persistence is not the same as compromise, but it changes the security posture because anything left behind after one execution can influence the next. Build artifacts, cached dependencies, temporary files, environment variables, and mis-scoped credentials are all more consequential when the runner is meant to outlive a single job.
Why Persistence Changes the Security Model
The security difference between ephemeral and persistent runners is mainly about trust boundary duration. An ephemeral runner limits exposure to the lifetime of one task; a persistent runner extends that boundary across multiple tasks and sometimes across administrative cycles, which increases the chance that leftover state becomes security-relevant.
That longer lifespan makes the runner closer to a shared host than a throwaway execution environment. If different workflows, repositories, or trust levels reuse the same machine, the operator has to think about separation of duties, state cleanup, and whether one job can influence another through residual files, tokens, or configuration.
From a governance perspective, persistence also turns the runner into an asset that needs ownership. Someone must decide who can register it, who can modify it, what it is allowed to access, and how its integrity is verified over time.
Common Security Implications
Persistence most often matters because the runner can keep sensitive material longer than intended. If secrets, signing keys, tokens, or cached credentials remain on disk or in memory after a job completes, the host can become a durable foothold for misuse, lateral movement, or unintended reuse in later executions.
It also increases the blast radius of code execution. A malicious or simply overbroad workflow step may be able to leave behind files, binaries, scheduled tasks, startup entries, or altered configuration that survives the job and affects future runs.
For that reason, persistent runners are especially sensitive in build and automation pipelines that process untrusted pull requests, third-party actions, or heterogeneous workloads. The risk is not only direct exfiltration, but also silent contamination of later jobs.
Operational Patterns That Matter
Security outcomes depend on how the runner is operated, not just whether it is self-hosted. Reuse across repositories, long-lived registration, shared host privileges, and weak cleanup all make persistence more dangerous. Strong segmentation, minimal privileges, and regular reimaging reduce the chance that a surviving state becomes an attack path.
Persistence can also be legitimate and even necessary for certain workloads, such as caching, local toolchains, or specialized build dependencies. In those cases, the question becomes how to preserve the operational benefit without preserving uncontrolled trust. That usually means treating the host as a managed system with explicit lifecycle, logging, and integrity checks rather than as disposable automation infrastructure.
Where persistence is unavoidable, the design should assume that the machine may be inspected, reused, or targeted after a previous job. That mindset helps distinguish harmless performance optimization from a durable execution foothold that can outlast the workflow that created it.
Risk and Threat Considerations
Persistent runners can retain attacker-controlled state after a job ends, which creates a durable foothold for secret theft, tampering, or reuse in later executions. The same persistence that helps performance can also help an attacker survive job boundaries and wait for a more valuable next run.
Failure mechanism: Leftover files, credentials, startup hooks, or modified configuration survive across jobs or reboots, allowing malicious changes to persist beyond the original execution context.
Impact: Later builds or automations may execute with compromised trust, exposing secrets, altering artifacts, or enabling further access without an obvious new intrusion event.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Persistent runners can retain and reuse credentials, tokens, and keys across jobs. |
| CM-6 — Configuration Settings | Runner persistence depends on durable host configuration that can survive reboots and jobs. | |
| SI-7 — Software, Firmware, and Information Integrity | Persistent runners can be tampered with between executions, affecting later job integrity. | |
| Recommendation — Rotate and revoke runner credentials so no secret persists beyond its intended use. Baseline and lock down runner configuration so persistent state cannot accumulate unchecked. Verify runner integrity before reuse to detect unauthorized changes left by prior activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Persistent runners require explicit teardown so residual access and state do not survive their intended lifecycle. |
| NHI-02 — Secret Leakage | Persistent runner state can retain secrets, tokens, and cached credentials after job completion. | |
| Recommendation — Remove runner registrations and attached secrets when the runner is retired or rebuilt. Prevent secrets from remaining on disk or in memory after each runner job finishes. | ||
Practitioner Guidance
Why practitioners should care: The central decision is whether the operational convenience of persistence outweighs the security cost of carrying state forward. If the runner touches sensitive workflows or untrusted code, persistence should be treated as a control choice, not a default deployment pattern.
Governance implication: Define who owns the host, who can register or reuse it, and what reset or verification standard is required before the next job. Persistent runners need explicit lifecycle rules because “always available” also means “always in scope.”
Practitioner takeaway: When persistence is required, reduce the amount of trust the runner retains between jobs, not just the amount of work it can do.
Related resources from NHI Mgmt Group
- What breaks when attackers can turn a GitHub Discussion into a command channel on a self-hosted runner?
- What breaks when attackers can run code on a self-hosted runner with access to secrets?
- What happens when a self-hosted runner allows unrestricted outbound traffic during a workflow run?
- Runtime Application Self-Protection
