What do security teams get wrong about dependency risk in agentic development?

Why Security Teams Misread Dependency Risk in Agentic Development

Dependency risk in agentic development is not just a package review problem. It is a trust problem embedded in the same workflow where code is proposed, modified, and executed. When an assistant can recommend a library, add it to a manifest, or trigger installation faster than a human can inspect it, the usual review gates arrive too late. That is why the issue sits closer to secure development than to a separate supply chain checklist, as highlighted in the OWASP Agentic AI Top 10 and the Analysis of Claude Code Security.

Teams also underestimate how quickly an agent can turn a small dependency choice into a broader execution path. A malicious or low-quality package can introduce code execution, data exfiltration, or hidden network calls, especially when the agent has permission to chain tools. NHIMG research on the OWASP NHI Top 10 shows that trust boundaries in agentic systems are often treated as static even though the workload is dynamic. In practice, many security teams encounter dependency abuse only after an agent has already pulled the package and executed the code path, rather than through intentional prevention.

How Dependency Trust Has to Work Inside the Coding Path

For agentic development, dependency controls need to operate where the assistant actually makes decisions. Current guidance suggests three controls belong in the developer path itself: package allowlisting, provenance and signature checks, and malware or policy scanning before installation or execution. That means the agent should not simply be told to "use approved packages"; it should be constrained by runtime policy and workflow guardrails that can block untrusted artifacts in the moment.

Practically, security teams should treat the assistant as an actor that can accelerate both good and bad choices. A safe setup usually combines repository policies, dependency scoring, software bill of materials coverage, and prompts or tool policies that prevent silent installs. The same principle applies to generated code that imports new modules without review. NIST AI Risk Management Framework helps frame this as a governance problem, while the CSA MAESTRO agentic AI threat modeling framework is useful for thinking about tool use, supply chain exposure, and agent autonomy together.

• Gate dependency installation through policy-as-code, not only developer preference.
• Require provenance, signature, or registry validation before an agent can import or update packages.
• Scan for malware, typosquatting, and suspicious transitive dependencies at request time.
• Keep SBOM data current so the agent path and the build path are aligned.
• Log assistant-suggested dependency changes separately from human-approved changes.

NHIMG’s reporting on incidents such as the Amazon Q AI Coding Agent Compromised and the Replit AI Tool Database Deletion shows how quickly tool-using systems can move from suggestion to harmful action. These controls tend to break down in fast-moving CI/CD environments because package approval, build execution, and agent autonomy often share the same trust boundary.

Common Failure Patterns and Where the Model Breaks Down

Tighter dependency control often increases developer friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially when teams want agentic coding to feel fluid. Best practice is evolving, and there is no universal standard for how much package autonomy an assistant should have by default. The practical mistake is assuming that the answer is either full freedom or full lockdown.

Edge cases usually appear in environments with private registries, monorepos, or ephemeral build agents. In those settings, an overzealous allowlist can block legitimate dependency updates, while a permissive setup lets the assistant fetch unreviewed transitive packages. Another common gap is focusing on malware detection alone. Malware scanning helps, but it does not solve provenance, maintainer compromise, or prompt-driven dependency substitution. The better pattern is layered trust: policy at the point of suggestion, verification at import, and auditability at build time. That is consistent with the direction of the State of Non-Human Identity Security, where visibility and control gaps repeatedly show up before teams have confidence in their controls.

Security teams should also distinguish between human developer intent and agentic execution. A person may approve a library name, while the agent resolves a different package, version, or transitive chain. When that happens, the failure is not just supply chain risk. It is an authorization gap inside the coding workflow, and that is why agentic development needs runtime governance, not just post hoc review.

Related resources from NHI Mgmt Group

• What do security teams get wrong about agentic supply chain risk?
• What do security teams get wrong about secrets in agentic development?
• What do security teams get wrong about AI coding-agent persistence?
• What do security teams get wrong about private repositories and internal pipelines?