They treat runners as disposable build machinery instead of identities that can preserve access. A self-hosted runner can become a durable foothold if offboarding, isolation, and monitoring are weak. If the runner still has access after the job ends, the attacker may still have a path back in.
Why This Matters for Security Teams
Workflow runners are often treated as temporary execution containers, but self-hosted runners can behave like persistent identities if they retain network reach, cached credentials, or registration tokens after a job completes. That is a governance failure, not just an infrastructure issue. NHI Management Group’s research shows 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why runner persistence belongs in the same control conversation as secrets, access, and offboarding. See also Ultimate Guide to NHIs and NIST SP 800-53 Rev 5 Security and Privacy Controls.
The mistake is assuming job completion equals access termination. In reality, a runner may still hold tokens, maintain trust with internal systems, or be reachable for re-use by the attacker who landed on it first. That makes persistence a post-execution control problem, not a build reliability concern. In practice, many security teams encounter runner persistence only after lateral movement or secret exfiltration has already happened, rather than through intentional lifecycle controls.
How It Works in Practice
Security teams need to model runners as managed NHIs with a lifecycle: provision, authenticate, execute, revoke, and verify teardown. For self-hosted runners, this means isolating each runner instance, limiting what it can reach, and ensuring that any job-specific credential is short-lived. Static registration tokens, long-lived cloud credentials, and reused runner images create the conditions for persistence. Current guidance suggests pairing ephemeral provisioning with explicit offboarding so the runner loses trust as soon as the workflow ends.
Operationally, the control set should include:
- Unique identity for each runner instance, not one shared pool identity.
- Just-in-time access for workflows, with credentials that expire automatically.
- Token revocation and secret rotation after job completion or failure.
- Network segmentation so a compromised runner cannot reach unrelated systems.
- Monitoring for unexpected process reuse, outbound connections, and re-registration attempts.
That approach aligns with how NHI risk is increasingly framed by NHIMG, including the visibility and rotation gaps highlighted in The State of Non-Human Identity Security. It also maps to NIST’s guidance on access control and continuous assessment, especially when paired with runtime checks from NIST SP 800-53 Rev 5 Security and Privacy Controls.
Where teams get tripped up is letting workflow runners inherit ambient permissions from the host, the CI service, or cached cloud auth. Once those permissions outlive the job, the runner stops being disposable machinery and starts acting like a durable foothold. These controls tend to break down in shared self-hosted runner fleets because ownership, teardown, and credential revocation are harder to enforce consistently.
Common Variations and Edge Cases
Tighter runner isolation often increases delivery overhead, requiring organisations to balance pipeline speed against the cost of stronger teardown and monitoring. That tradeoff becomes visible in hybrid environments, where some runners are ephemeral and others are long-lived for performance or hardware access. Best practice is evolving here, and there is no universal standard for every CI/CD platform yet.
Edge cases matter. GPU runners, air-gapped build nodes, and reusable warm pools can reduce startup time, but they also increase the risk that state survives between jobs. Likewise, if a runner is used to access third-party SaaS or cloud APIs, the persistence problem may sit in the external token store rather than on the machine itself. Security teams should extend the same offboarding logic to API keys, OAuth grants, and cloud role sessions, not just the runner host. The Salt Typhoon US telecoms breach is a reminder that stolen credentials plus weak lifecycle controls can turn access into persistence.
Where this guidance breaks down most often is in legacy CI environments that cannot issue per-job identities or enforce immediate revocation, because the platform itself was built around shared service credentials.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF 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-03 | Runner persistence is driven by weak rotation and stale credentials. |
| OWASP Agentic AI Top 10 | A-04 | Autonomous execution systems need lifecycle controls to prevent retained access. |
| CSA MAESTRO | IAM-02 | MAESTRO addresses identity, access, and isolation for agentic workloads. |
| NIST AI RMF | AI RMF supports governance for dynamic, goal-driven execution contexts. | |
| NIST CSF 2.0 | PR.AC-4 | Access management must prevent standing access from surviving workflow completion. |
Treat every runner credential as short-lived and revoke it immediately after workflow completion.
