Mutable dependency

A mutable dependency is a workflow component that can change after it has been reviewed, such as a version tag or reusable action reference. The danger is that the approved object and the executed object are no longer the same, which undermines trust, traceability, and access control.

Expanded Definition

Mutable dependency describes a dependency reference that can be altered after approval, even if the surrounding workflow remains unchanged. In NHI and agentic AI pipelines, this often appears as a floating tag, branch reference, or reusable workflow pointer that resolves to a different artifact later. That makes the reviewed object and the executed object diverge, which weakens provenance, repeatability, and access control.

The core issue is not that dependencies change over time, but that the change is not locked to the original review state. In secure software and identity operations, this sits close to supply chain risk and execution integrity. The NIST Cybersecurity Framework 2.0 treats integrity and change management as governance essentials, while NHI practice requires the same discipline for machine identities, tokens, and automation paths. Usage in the industry is still evolving because teams may use the term to describe package versions, Git references, container tags, or workflow actions.

The most common misapplication is treating a mutable reference as if it were an immutable release artifact, which occurs when teams approve a tag or branch without pinning the executed version.

Examples and Use Cases

Implementing mutable dependency controls rigorously often introduces release friction, requiring organisations to weigh faster updates against reproducibility and auditability.

• A CI pipeline references a reusable action by tag instead of commit SHA, so later tag changes alter build behaviour without a new approval.
• An agentic workflow calls an external tool through a versioned endpoint, but the endpoint alias is repointed to a different implementation after review.
• A container image is deployed from a moving tag such as latest, creating a mismatch between the scanned image and the running image.
• A package installation resolves from a lockless manifest, allowing a dependency update to change runtime permissions or network behaviour unexpectedly.
• A supply chain incident like the LiteLLM PyPI package breach shows why pinned references and reviewable provenance matter when code execution depends on third-party artifacts.

For implementation guidance, teams often pair pinned references with the identity and provenance expectations described by NIST Cybersecurity Framework 2.0, especially where automated build and deployment paths have execution authority.

Why It Matters in NHI Security

Mutable dependencies become an NHI problem because machine identities often authorize automated retrieval, execution, and delegation at scale. If a dependency can change after review, the identity that approved the action is no longer the identity that ultimately executed it. That breaks trust boundaries and can turn a legitimate automation path into an unexpected privilege path. In NHI governance, this is especially dangerous when secrets, service accounts, or agent tools are involved, because the executed artifact may inherit access that was never intended for the reviewed version.

NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks, with 77% causing tangible damage, and mutable references often worsen the blast radius when compromised build paths propagate silently. The risk also extends to ecosystem components: a pinned control plane is only as strong as its least stable dependency. That is why provenance, version pinning, and reviewable promotion gates are central to trustworthy NHI operations. The Ultimate Guide to NHIs frames this as part of broader visibility and lifecycle control, not just software hygiene. Organisations typically encounter the consequence only after a compromised release, poisoned workflow, or unexpected permission change, at which point mutable dependency management becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does a dependency compromise become an identity incident?
• How should teams slow down malicious dependency updates without breaking delivery?
• What is the difference between automating dependency updates and granting them blind trust?
• Should organisations allow pull_request_target for automated dependency workflows?