The machine identity and permission set used by a CI/CD runner while a job executes. It may include repository tokens, cloud federation claims, package publishing rights, and secret access, which makes it a high-value non-human identity requiring explicit scope control.
Expanded Definition
A workflow runner identity is the ephemeral or semi-persistent machine identity assumed by a CI/CD runner while executing pipeline steps. In practice, it is not just a login or token. It is the effective permission envelope that may reach source code, cloud control planes, artifact registries, signing services, and secret stores.
Definitions vary across vendors because some platforms treat the runner as part of the build system, while others treat it as a distinct NHI with federated trust, short-lived credentials, and scoped execution rights. For NHI governance, the key distinction is whether the runner can be separately identified, constrained, monitored, and revoked. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to manage identity permissions as a control objective, not an implementation detail. A workflow runner identity becomes especially sensitive when it can mint downstream tokens or impersonate production-deploying automation. The most common misapplication is treating the runner as a generic service account, which occurs when pipeline privileges are copied from human admin access instead of being explicitly designed for each job.
Examples and Use Cases
Implementing workflow runner identity rigorously often introduces release friction, requiring organisations to weigh deployment speed against tighter credential scoping, short-lived access, and more frequent approvals.
- A GitHub Actions runner receives a federated cloud role only for the duration of a build, then loses access as soon as the job completes. This pattern aligns with the risk lessons in the GitHub Action tj-actions Supply Chain Attack, where CI/CD trust was exploited to reach secrets.
- A self-hosted runner is limited to pulling dependencies and publishing artifacts, but cannot read production secrets. That separation reduces blast radius if the runner host is compromised.
- A release pipeline uses a dedicated identity for code signing, with approval gates and hardware-backed keys, rather than reusing a broad deployment credential.
- A container build job accesses a package registry through a narrowly scoped token, while repository write access remains unavailable to the same runner identity.
- For broader context on how runner identities fit into NHI governance, the Ultimate Guide to NHIs and Top 10 NHI Issues show why pipeline credentials must be treated as first-class identities, not disposable plumbing.
The NIST guidance on digital identity is helpful for understanding assurance, but runner identity design also depends on platform-specific federation patterns and job isolation models that are still evolving across the industry.
Why It Matters in NHI Security
Workflow runner identities are high-value because they sit at the intersection of source code, secrets, and production change paths. When they are overprivileged, a single compromised job can leak credentials, tamper with build outputs, or push malicious artifacts into downstream environments. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes runner compromise especially damaging. That is why NHI controls for scoping, rotation, and revocation matter as much in build systems as they do in production systems.
Runner identity also affects Zero Trust design. If the pipeline can authenticate broadly and inherit standing access, every build becomes a potential privilege escalation path. The safer model is to bind each runner to a minimal, job-specific trust boundary and verify every action it performs. Organisations typically encounter credential theft, supply chain tampering, or unexpected package publication only after a pipeline incident, at which point workflow runner 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers NHI lifecycle and privileged machine identities used by automation and CI/CD. |
| OWASP Agentic AI Top 10 | A-07 | Applies where automated agents or runners can execute actions and call tools with authority. |
| NIST CSF 2.0 | PR.AC-4 | Identity and access permissions for automated systems are core to least-privilege access control. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous verification of non-human actors and their access context. | |
| NIST AI RMF | AI and automated workflow governance must address access, provenance, and operational risk. |
Inventory runner identities, scope their privileges, and revoke them immediately after each job.
