Should organisations treat CI/CD runners as privileged identities?

Why This Matters for Security Teams

CI/CD runners are not just build utilities. In many environments they can access source code, deploy artefacts, read secrets, assume cloud roles, and trigger production changes. That makes them privileged non-human identities, even when they are short-lived and automatically provisioned. The risk is not theoretical: GitGuardian reported that 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations in The State of Secrets Sprawl 2026.

Teams often miss this because runners are framed as infrastructure, not identities. That distinction breaks down the moment a pipeline token can call a cloud API or retrieve a secret from a vault. Current guidance from the OWASP Non-Human Identity Top 10 treats these privileges as identity risk, not simply server hardening. The practical question is whether the runner can be constrained, observed, and revoked with the same rigor as any other privileged NHI. In practice, many security teams encounter runner abuse only after a compromised workflow has already deployed malicious code or exfiltrated secrets, rather than through intentional control design.

How It Works in Practice

Managing runners as privileged identities starts with reducing standing access. A runner should receive only the permissions needed for the specific job, for the shortest useful time, with trust tied to workload identity rather than a static shared secret. That usually means short-lived tokens, OIDC-based federation, and policy decisions that evaluate the job context at request time. For agentic or highly dynamic build systems, this is closer to runtime authorisation than traditional RBAC.

In mature setups, the pipeline identity is bound to a workload identity primitive, while secrets are issued just in time and revoked automatically on completion. This narrows blast radius when a job is compromised. It also makes logs more meaningful, because the security team can trace which workflow, commit, branch, repository, or environment requested the privilege. The CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack both show how quickly a pipeline can become the path from code execution to credential exposure.

• Issue per-job credentials instead of reusing long-lived runner tokens.
• Scope cloud roles and vault access to one repository, branch, or deployment target where possible.
• Validate trust with signed artefacts, policy-as-code, and strong provenance checks.
• Log secret access, role assumption, and deployment actions as identity events.
• Revoke credentials immediately after the job finishes or fails.

The OWASP Non-Human Identity Top 10 aligns well with this approach, especially where credential misuse and excessive trust are the real failure modes. These controls tend to break down when self-hosted runners are reused across many repositories with shared admin tooling, because the identity boundary becomes too coarse to enforce least privilege.

Common Variations and Edge Cases

Tighter runner control often increases operational overhead, requiring organisations to balance release velocity against blast-radius reduction. That tradeoff is real, especially for high-frequency builds, ephemeral test environments, and large monorepos. Current guidance suggests that organisations should treat shared runners and long-lived self-hosted agents as higher risk than isolated, ephemeral runners, but there is no universal standard for every deployment pattern yet.

One common edge case is “trusted” internal CI where teams assume private repositories are safe. That assumption is weak. GitGuardian found in The State of Secrets Sprawl 2025 that internal repositories are six times more likely to contain secrets than public ones. Another edge case is pipeline tooling that needs broad cloud permissions for infrastructure provisioning. In those environments, the answer is not to ignore privilege, but to split duties: keep build, deploy, and infrastructure functions separate, then apply explicit approval gates and stronger monitoring to the highest-risk jobs. The Guide to the Secret Sprawl Challenge is useful context for why detection alone is not enough without revocation and lifecycle control.

Where organisations are beginning to use autonomous agents inside CI workflows, the risk profile moves even further from static IAM assumptions. Behaviour can change from run to run, so the practical answer is intent-based authorisation, ephemeral secrets, and workload identity rather than broad role assignment. That model is still evolving, but it is the direction most defensible programmes are taking.

Related resources from NHI Mgmt Group

• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations treat OAuth tokens as privileged identities?
• How should security teams govern non-human identities at scale?