A CI runner identity is the set of credentials and permissions a build or test runner uses while executing pipeline tasks. In NHI terms, it is a machine identity with real authority, often able to read secrets, access repositories, and publish artefacts if controls are too broad.
Expanded Definition
A ci runner identity is the machine identity used by a build runner, test agent, or pipeline worker to authenticate and authorize actions during software delivery. It is not just a login token; it is an operational identity with permissions that can reach source code, secrets, artefact stores, package registries, and deployment targets.
In NHI terms, the runner identity should be treated like any other privileged NHI, with lifecycle controls, scoped entitlements, and clear ownership. Definitions vary across vendors, especially when CI systems blur the line between the runner process, the job token, and the service account attached to an executor. That ambiguity is exactly why guidance from NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs is useful: both push practitioners toward inventory, governance, and least privilege rather than relying on implicit trust in pipeline tooling.
The most common misapplication is treating runner credentials as disposable build metadata, which occurs when long-lived tokens are embedded in shared images or reused across jobs with different privilege needs.
Examples and Use Cases
Implementing CI runner identity rigorously often introduces pipeline friction, requiring organisations to weigh faster builds against tighter isolation, shorter token lifetimes, and more frequent reauthentication.
- A self-hosted runner pulls private dependencies from a package registry, but the identity is limited to read-only access and time-bound repository scopes.
- A deployment job uses a separate runner identity from the test stage so that code validation cannot publish artefacts or modify production configurations.
- A monorepo pipeline issues one ephemeral job token per workflow run, reducing reuse risk and aligning with the least-privilege patterns discussed in the Top 10 NHI Issues.
- A security team isolates runners handling release signing so that only a hardened executor can reach key material and only for a narrow JIT window.
- After an incident review, a platform team compares runner activity with the attack patterns documented in JetBrains GitHub plugin token exposure to redesign token scope and rotation.
For identity assurance and pipeline trust boundaries, organisations often map these controls to NIST Cybersecurity Framework 2.0 and related access governance practices rather than relying on a single CI vendor control model.
Why It Matters in NHI Security
CI runner identities matter because they sit at a high-trust junction between source, secrets, and deployment. When they are overprivileged, a single compromised job can become a pathway to repository tampering, secret exfiltration, malware insertion, or release manipulation. That risk is not theoretical: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which broadens the attack surface and makes runner identities especially attractive targets.
The governance problem is often not the runner itself but everything attached to it: cached credentials, inherited environment variables, default secrets injection, and shared executor state. In a zero trust model, a runner should never inherit more authority than a single job requires, and its access should be continuously evaluated alongside artefact integrity and secret handling. The breach patterns covered in 52 NHI Breaches Analysis show how quickly a build identity can become a production foothold when rotation and scoping are weak.
Organisations typically encounter runner identity risk only after a pipeline compromise, at which point the identity becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses secret handling and excessive privilege risks common to CI runner identities. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access and entitlement review are central to runner identity governance. |
| NIST Zero Trust (SP 800-207) | PL.AA | Zero Trust requires strong identity verification and session-specific authorization for workload access. |
Scope runner tokens tightly, rotate them often, and remove any embedded secrets from pipeline configs.
