Runtime Dependency Sprawl

Expanded Definition

Runtime dependency sprawl describes the uncontrolled growth of dependencies that an autonomous workload resolves only when it is executing. In agentic systems, that can include Python or JavaScript packages, OCI container images, binaries, model-adjacent tools, remote APIs, and internal services that the agent discovers or invokes on demand. The security issue is not just volume. It is the fact that each runtime fetch or invocation expands the trust boundary at the moment of execution, when the system may already have decision-making authority.

This term is closely related to supply chain risk, but it is narrower than generic dependency management because it focuses on what is introduced during live execution rather than what was approved at build time. The distinction matters in AI and agentic environments, where an agent may branch into new tools or pull helper libraries based on context. That means security teams need visibility into execution paths, not only source code and image manifests. The NIST Cybersecurity Framework 2.0 is useful here because it frames the need to govern, identify, protect, detect, respond, and recover across dynamic risk conditions.

The most common misapplication is treating runtime dependency sprawl as a build-time software composition problem, which occurs when organisations review approved artifacts but ignore what agents download, instantiate, or call after deployment.

Examples and Use Cases

Implementing controls against runtime dependency sprawl rigorously often introduces latency, policy friction, and more frequent allowlist maintenance, requiring organisations to weigh execution flexibility against stronger runtime assurance.

• An AI coding agent pulls a new package from a public registry to satisfy a tool call, even though the package was never reviewed in the release pipeline. That creates an execution-time trust decision that static scanning will not catch.
• A customer support agent invokes a third-party summarisation API during a live workflow, and the service later changes behaviour or retention terms. Teams need to know when the agent began relying on that external dependency.
• A containerised agent downloads a helper binary at startup from an internal artifact repository, but the repository contains multiple versions with inconsistent signing practices. The problem is not only provenance, but the sprawl of possible runtime choices.
• An agent connects to a new internal microservice discovered through orchestration metadata. This may be legitimate, but it still expands the operational attack surface and should be governed like any other privileged integration.
• Security reviewers track only the base image and lockfile, while the agent’s workflow uses retrieval, tool execution, and remote code execution paths that are resolved dynamically. Guidance from OWASP’s guidance for LLM applications is relevant because these systems frequently combine model output with external tools and dependencies.

Why It Matters for Security Teams

Runtime dependency sprawl increases the chance that an autonomous system will inherit hidden vulnerability, policy, or data-handling risk after deployment. For security teams, the operational challenge is to govern not just what is packaged, but what the system is allowed to discover, fetch, execute, and trust during a live task. That requirement becomes more urgent when an AI agent has execution authority, because every additional dependency can alter the scope of access, observability, and incident response.

This is also where identity and privilege controls intersect with agentic AI. If a runtime dependency is a service, API, or tool, then its credentialing, authentication, and authorization model should be explicit and revocable. NHI governance becomes relevant when non-human actors are granted tokens or certificates to reach those dependencies, especially in environments that rely on short-lived secrets, delegated permissions, or service-to-service trust. The same logic applies to monitoring: teams need to know which runtime dependencies were used, by which agent, and under what policy conditions.

Practitioners should treat unresolved runtime dependency growth as a governance gap, not a mere engineering inconvenience. CISA software supply chain guidance reinforces the need to understand provenance and change control across the full lifecycle, including operational use. Organisations typically encounter the consequences only after an agent reaches an unexpected service, pulls a risky library, or triggers an incident that cannot be reproduced from the original build artefact, at which point runtime dependency sprawl becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when a dependency CVE depends on header injection but the runtime blocks it?
• How do organisations reduce the impact of AI-driven dependency sprawl?
• What should teams do after a compromised dependency reaches a build or runtime host?
• Runtime dependency trust