Because the runner identity is often a workload identity with access to metadata services, tokens, and deployment resources. Malicious install code can use that reach to discover secrets or request temporary credentials. The risk is highest when build systems share the same network path and trust assumptions as production workloads.
Why Package Installs Become an Identity Problem in Build Systems
Package installs are not just supply chain events. In cloud build environments, they often execute with the same workload identity that can reach metadata services, request short-lived tokens, read deployment variables, and interact with internal APIs. That turns a routine install step into an identity exposure point, especially when installers, hooks, or transitive dependencies run arbitrary code during setup. Guidance in the NIST Cybersecurity Framework 2.0 reinforces the need to reduce trust in execution paths that can expand access unexpectedly.
For NHI practitioners, the key issue is not whether the package is “trusted” in the abstract. The issue is whether the build runner has been given enough reach that a malicious install script can pivot from code execution into credential discovery or token minting. NHIMG research on LiteLLM PyPI package breach shows how package-level compromise can become credential theft when runtime access is too broad. In practice, many security teams discover this only after a build pipeline has already been used as the easiest path into production trust.
How It Works in Practice
The risk comes from the overlap between code execution and identity scope. During package installation, build tools may run scripts, compile native extensions, or fetch secondary dependencies. If the runner can query instance metadata, access secret stores, or assume cloud roles, malicious install code can use that moment to extract secrets or request new credentials. This is why static IAM assumptions fail in build systems: the runner does not follow a fixed human-like pattern, and its behavior depends on whatever the package author placed in the install path.
Current guidance suggests treating build runners as high-risk workloads with narrow, task-specific access. That usually means:
- Using workload identity instead of shared long-lived secrets, so the build gets cryptographic proof of what it is, not a reusable credential.
- Issuing just-in-time, ephemeral credentials per build job and revoking them when the job completes.
- Blocking direct access to metadata services unless the job genuinely needs them.
- Applying real-time authorization at request time, not just pre-defined role assignment before the build starts.
- Separating package retrieval, compilation, and deployment so an install step cannot reach downstream promotion paths.
This is consistent with NHI guidance in the Ultimate Guide to NHIs and with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. For build security, the practical goal is to make package install activity unable to turn itself into broader environment access. These controls tend to break down when shared runners can see production-adjacent credentials because one compromised install step then inherits trust that was never meant for arbitrary code.
Common Variations and Edge Cases
Tighter build isolation often increases operational overhead, requiring organisations to balance release speed against the cost of more ephemeral identity controls and stricter network segmentation. The tradeoff is especially visible in monorepos, containerized CI, and multi-tenant runners, where teams want fast caching and broad dependency reuse but those same efficiencies enlarge the blast radius of a malicious install.
Best practice is evolving, but there is no universal standard for this yet. Some environments can block install-time code execution entirely, while others must allow it for native builds or language ecosystems that compile from source. In those cases, the safer pattern is to pair install-time restrictions with runtime policy enforcement and very short TTLs for any token the runner can obtain. The 52 NHI Breaches Analysis and NHIMG’s Top 10 NHI Issues both reflect the same pattern: once a non-human workload can chain access from one service to another, the initial package install is no longer a simple dependency action, but a potential identity escalation path.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Install-time code can abuse overlong or shared NHI credentials. |
| OWASP Agentic AI Top 10 | A2 | Autonomous package execution can chain actions beyond intended build scope. |
| CSA MAESTRO | Build pipelines need workload identity and policy checks for autonomous execution paths. | |
| NIST AI RMF | Runtime evaluation and governance reduce unpredictable agent-like workload behavior. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access review apply directly to build runner identities. |
Use short-lived NHI credentials for builds and revoke them immediately after each job ends.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
