When should organisations revoke GitHub runners and other automation workers?

Why This Matters for Security Teams

Automation workers are not just build helpers. They often hold deployment tokens, cloud credentials, package publishing rights, and privileged access to repositories or infrastructure. Once a runner or other worker is no longer trustworthy, it can preserve access long after the obvious malware is gone. That is why current guidance treats uncertain worker identity as a revocation event, not a troubleshooting issue. The lifecycle view in the NHI Lifecycle Management Guide is useful here: if registration, attestation, or recent behaviour cannot be verified, the identity should be considered stale.

This matters because worker compromise is often hidden inside normal operational noise. A GitHub runner that looks healthy may still be reusing cached credentials, reaching into secret stores, or acting on behalf of multiple pipelines. The OWASP Non-Human Identity Top 10 calls out this class of risk as a governance problem, not only a malware problem, because the identity boundary is what matters after initial infection. In practice, many security teams encounter persistent worker abuse only after secrets have been exfiltrated or releases have been tampered with, rather than through intentional decommissioning.

How It Works in Practice

Revocation should be tied to trust signals, not calendar age alone. For GitHub runners and similar automation workers, the practical test is whether the team can confirm who registered the worker, what image or binary it was built from, whether it has attested integrity, and whether its recent actions match expected workload behaviour. If any of those checks fail, rebuild from a clean baseline instead of trying to “clean” the machine in place. That approach is consistent with Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the broader control expectations in OWASP Non-Human Identity Top 10.

• Revoke the worker identity first, then invalidate any tokens, certificates, or cached secrets it could reach.
• Reimage or redeploy from a known-good template, rather than attempting ad hoc repair on a potentially compromised host.
• Review repository, CI/CD, cloud, and secret-manager permissions to confirm the worker had no residual standing access.
• Check for lateral movement through deployment tools, package registries, and artifact stores before restoring service.

Use event-driven revocation when a worker’s provenance is uncertain after incident response, suspicious outbound traffic, unexpected job execution, or unexplained credential use. The State of Secrets Sprawl 2025 is a reminder of why this matters: 96% of organisations store secrets outside secrets managers in vulnerable locations, so a compromised worker can quickly become a secrets distribution point. These controls tend to break down when runners are long-lived, self-hosted, and allowed broad network reach because cleanup cannot prove the worker has not already copied credentials elsewhere.

Common Variations and Edge Cases

Tighter revocation rules often increase rebuild overhead, so teams need to balance operational continuity against the risk of leaving a questionable worker online. That tradeoff is especially visible in self-hosted runners, ephemeral build fleets, and automation workers embedded in third-party platforms. Current guidance suggests treating cloud-managed ephemeral runners differently from long-lived self-hosted machines, but there is no universal standard for this yet. The safest pattern is to use short-lived identity, scoped permissions, and per-job issuance so revocation is cheap when trust is lost.

Some environments also mix automation workers with service accounts, API keys, and deployment bots, which can blur the line between host compromise and identity compromise. In those cases, revoke both the worker and any associated secrets, then reissue only after the baseline is rebuilt and validated. The Guide to NHI Rotation Challenges is useful when deciding whether rotation alone is enough or whether full retirement is required. For a broader offensive view, the Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly automation can be turned into a secret-harvesting foothold.

Related resources from NHI Mgmt Group

• What is the main risk when automation systems store ServiceNow credentials?
• Should organisations require reproducible evidence from AI red-team tests?
• How should teams respond when a GitHub personal access token is exposed in an AI chat history?
• Why are GitHub audit logs not enough to detect PAT misuse?