The credentialed identity used by a CI/CD runner or build agent to execute automation tasks. It is often broader than teams realise because it can inherit repository, cloud, and deployment permissions that make a single compromised job highly valuable to an attacker.
Expanded Definition
Runner Identity is the credentialed non-human identity assigned to a CI/CD runner, build agent, or similar automation worker so it can fetch code, invoke tools, deploy artifacts, and write back status. In NHI governance, the key issue is not the runner itself but the permissions attached to that identity, which often span source control, container registries, cloud APIs, secret stores, and deployment targets. NIST Cybersecurity Framework 2.0 frames this as an access-governance problem: the identity must be identifiable, accountable, and limited to the exact work it performs.
Definitions vary across vendors when runners are managed by SaaS CI systems, self-hosted agents, or ephemeral workloads, but the security meaning stays the same: the runner identity is the trust boundary that turns automation into authorized action. In practice, it should be treated as a distinct NHI with lifecycle controls, rotation, and offboarding, not as an implementation detail hidden inside a pipeline. The most common misapplication is granting a runner a broadly scoped service account or cloud role because the job "needs to deploy," which occurs when convenience overrides least-privilege review.
Examples and Use Cases
Implementing Runner Identity rigorously often introduces pipeline friction, requiring organisations to weigh delivery speed against tighter access scoping, short-lived credentials, and more frequent approvals.
- A self-hosted build agent uses a dedicated identity to pull source, access a signing service, and publish a release artifact, with no interactive login allowed.
- A GitHub Actions or GitLab runner authenticates to cloud infrastructure through a federated workload identity rather than a long-lived API key, reducing secret exposure. See the NIST Cybersecurity Framework 2.0 for access-management alignment and the Ultimate Guide to NHIs for lifecycle context.
- A production deployment job receives a narrowly scoped token that can update only one namespace or account, instead of inheriting repository admin or subscription-owner rights.
- After a breach review, teams trace a malicious pipeline step to the runner identity that had access to a secrets manager, following patterns seen in the JetBrains GitHub plugin token exposure.
- Ephemeral runners are provisioned per job and destroyed immediately after completion, limiting reuse and making stolen credentials less durable.
Why It Matters in NHI Security
Runner Identity is one of the highest-value NHI types because it sits at the intersection of code, credentials, and infrastructure. When it is over-privileged, a single compromised build can leak secrets, tamper with signed artifacts, or trigger unauthorized deployments. NHIMG research shows that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, a combination that turns runners into attractive pivot points. The same risk appears in incident patterns documented across the Top 10 NHI Issues and the 52 NHI Breaches Analysis.
Operationally, the discipline is to bind each runner identity to a clear purpose, short credential lifetime, strong auditability, and explicit revocation paths after compromise or pipeline decommissioning. Organisations typically encounter the consequences only after a poisoned build, token theft, or supply-chain incident, at which point 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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Runner identities are NHI workloads that need scoped lifecycle and access controls. |
| NIST CSF 2.0 | PR.AA | Identity and access management governs machine identities used by CI/CD runners. |
| NIST Zero Trust (SP 800-207) | 4.1 | Zero Trust requires each workload identity to be authenticated and authorized per request. |
| NIST SP 800-63 | Digital identity assurance principles inform how machine identities are issued and trusted. | |
| OWASP Agentic AI Top 10 | A1 | Autonomous execution identities can overreach when tool access is not tightly constrained. |
Assign each runner a distinct identity, restrict permissions, and revoke it immediately after use or decommissioning.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
