Coding Agent Dependency Security: Privileged Installs

Coding agents should not install new dependencies as an ordinary coding step. A package install is a privileged operation. Treat it with policy approval, registry mediation, lockfile enforcement, provenance checks, and human review before new external code enters the project.

This article is for security engineering leaders and platform teams governing agentic software delivery. The uncomfortable part is timing. A human might search for a library, read its repository, check maintainers, and pause before installing it. A coding agent can invent a dependency, run pip install or npm install, update the lockfile, and execute install-time code before a reviewer sees the name.

How hallucination becomes supply-chain risk

Package hallucination happens when a model references a package that does not exist. Slopsquatting is the attack pattern that follows: someone registers the plausible invented name and waits for humans, generated documentation, or agents to install it.

This is different from classic typosquatting. The name may not be one character away from a popular package. It may be a believable package name, a framework mix-up, or a model-generated blend of real concepts. That weakens controls based only on edit distance.

The research brief gives concrete scale. Spracklen et al. tested 16 code-generation models across 576,000 Python and JavaScript samples and reported 205,474 unique hallucinated package names. In sampled prompts, 43 percent of hallucinated packages repeated in all 10 repeated runs, while 39 percent never repeated. That creates both noise and a predictable target set.

Newer models improve, but the failure mode remains. A 2026 frontier-model replication cited in the brief reports hallucination rates from 4.62 percent to 6.10 percent, plus 127 package names invented by all five tested models. That is enough to matter when agents can act at machine speed.

Registry existence is not approval

Lasso Security registered the hallucinated PyPI package huggingface-cli as an empty proof of concept and reported more than 30,000 authentic downloads in three months. Aikido's 2026 field report described suspicious package names consistent with slopsquatting patterns, including react-codeshift, spreading through agent-skill repositories and continuing to receive daily downloads after registration.

The lesson is blunt: a package can exist because models started naming it. Download counts can be polluted by generated docs, agent behavior, and mistaken installs. Existence in a registry is a weak trust signal.

Where conventional SCA falls short

Software composition analysis still matters. GitHub Dependency Review can surface direct and indirect dependency changes, lockfile diffs, vulnerable versions, licenses, release dates, dependency age, and usage. OSV-style scanners help find known vulnerabilities across manifests, lockfiles, SBOMs, and containers.

But a brand-new slopsquatted package may have no advisory. A package may be signed and still inappropriate. npm registry signature verification through npm audit signatures can confirm registry signatures when signing keys are available, but provenance does not prove the package is maintained, non-malicious, or needed.

The strongest pattern is proposal now, install after approval.

Coding agent dependency security controls

Classify dependency installation as a privileged agent tool action. Agents can propose dependencies. They should not silently perform first-time installs from public registries in production-like environments.

• Block direct egress from agent sandboxes to public package registries.
• Route package fetches through an internal proxy with allowlists, quarantine, metadata checks, and reviewed artifact caching.
• Allow deterministic installs from approved lockfiles.
• Deny or require approval for npm install <new>, pip install <new>, unreviewed npx, git URL dependencies, and unpinned ranges.
• Use pip --require-hashes and pinned requirements where supported.
• Use npm ci for lockfile-controlled JavaScript installs.
• Restrict install scripts and run installs in no-secrets, network-restricted sandboxes.

Do not review only the manifest. A malicious or hallucinated package can enter through transitive dependencies, lockfile changes, source builds, or URL-based dependencies. Full-tree review matters.

What an agent should propose

A useful dependency-change proposal includes package name, registry, version, publisher or maintainer, package age, repository URL, license, install scripts, provenance or signature status, vulnerability status, and the reason an existing dependency cannot satisfy the task.

The reviewer should be able to answer: is this package already approved, is the name plausibly hallucinated, does the project have real history, does it run install scripts, does the lockfile add unexpected transitives, does the license fit, and is there a safer dependency already in use?

An approved dependency catalog makes this easier. Each approved package should have an owner, permitted version policy, update cadence, license status, and exception expiry. Without ownership, approvals become permanent by accident.

Monitoring signals

Log agent package behavior as security-relevant activity: package-not-found errors, repeated install attempts, package-manager invocations, npx execution, URL dependencies, postinstall scripts, source builds, and registry fallback behavior.

Package-not-found errors deserve attention. In a human workflow they may be typos. In an agent workflow, repeated missing package names can reveal hallucinated dependencies before an attacker registers them.

Model-side improvements are welcome. Trend Micro found reasoning-enhanced agents and MCP validation reduce phantom dependencies, but do not eliminate the threat. Assume the model can still be wrong. Then design the runtime so a wrong package name cannot become running code without review.