Use package allowlisting, provenance validation, and strict egress controls for build environments. Then limit the agent’s ability to resolve or fetch arbitrary dependencies. The point is to ensure that package selection is governed by policy, not by a model’s guess about what package name looks plausible.
Why This Matters for Security Teams
Slopsquatting and dependency poisoning turn software supply chain trust into a naming problem. A model or agent can suggest a package that sounds credible, but if the build pipeline installs it without verification, the result can be malicious code entering production through ordinary automation. That is why this issue belongs in build security, release governance, and dependency policy, not just in prompt review.
Security teams often underestimate how fast this failure propagates. One bad package name can reach CI, container images, and downstream services before anyone notices, especially when dependency installs are unattended. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this as a control and governance problem: approved sources, controlled execution, and evidence-backed change management matter more than trust in the model’s output. In practice, many security teams encounter dependency poisoning only after a build artifact has already been promoted, rather than through intentional review.
How It Works in Practice
The practical defence is to remove ambiguity from package acquisition and make the pipeline deterministic. Teams should maintain an allowlist of approved registries and packages, require signed or otherwise verified provenance, and block outbound network access from build runners except to explicitly approved sources. For AI-assisted development workflows, the agent should be constrained so it cannot install packages, resolve dependencies, or rewrite lockfiles without policy checks and human approval.
Provenance validation is especially important because a package name alone tells you almost nothing about origin or integrity. Where available, organisations should verify publisher identity, signature status, and dependency metadata before promotion. This maps well to established software supply chain practices in the Supply-chain Levels for Software Artifacts framework and the OWASP guidance for LLM applications, both of which emphasise trust boundaries and untrusted input handling.
- Pin dependency versions and review lockfiles as controlled artifacts.
- Allow only vetted registries, mirrors, or internal package repositories.
- Block direct internet access from build and test environments unless explicitly required.
- Alert on package-name changes, new transitive dependencies, and unexpected publisher shifts.
- Require human approval for dependency additions suggested by an AI agent.
Detection should complement prevention. Build telemetry, artifact attestation, and dependency diffing help spot when a model has proposed an unusual or typo-squatted package, or when a dependency graph changes outside normal patterns. These controls tend to break down when teams rely on permissive CI runners with broad egress and no lockfile enforcement because the environment itself can silently accept whatever the agent suggests.
Common Variations and Edge Cases
Tighter dependency controls often increase friction for developers and platform teams, requiring organisations to balance speed against supply chain assurance. That tradeoff is real, especially in fast-moving CI/CD pipelines where teams want automation to stay productive. Best practice is evolving on how much autonomy an AI coding agent should have, but there is no universal standard for allowing it to fetch packages directly.
Edge cases usually appear in environments with private package mirrors, polyglot stacks, or ephemeral build agents. Internal registries reduce exposure, but they still need provenance checks, access logging, and periodic review of mirrored content. For large-scale agentic workflows, the governance question is not only what the model may recommend, but also what identity it uses to execute tool actions and reach dependency sources. That is where identity controls intersect with software supply chain security: the agent’s execution identity should be narrow, auditable, and revocable.
Teams should also be careful not to treat all dependency risk the same way. Slopsquatting is often a naming and discovery problem, while dependency poisoning can involve tampering with legitimate packages, dependency confusion, or compromised maintainers. The response is related but not identical. Strong package policy, provenance, and egress restriction reduce both risks, but high-assurance environments may also need internal package curation and manual review for critical builds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Secure development policy and controlled changes are central to dependency approval. |
| NIST AI RMF | GOVERN | AI governance is needed when agents can recommend or trigger package installation. |
| OWASP Agentic AI Top 10 | Tool Misuse | Agent tool access can be abused to fetch or install untrusted dependencies. |
| NIST SP 800-53 Rev 5 | SA-12 | Supply chain protection covers provenance, sourcing, and verification of components. |
| MITRE ATLAS | AML.TA0001 | Poisoned outputs and manipulative model behaviour can drive unsafe package suggestions. |
Define approved dependency sources and enforce them through software build and release policy.
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
