AI coding agents are very good at producing a plausible import statement. Plausible is not the same as verified.
When an assistant invents a package name, an attacker can register that name first. When it chooses a real package, a loose version range or install script can still introduce risk. The problem is not that AI writes code. The problem is that the dependency decision can look routine while bypassing the checks developers normally perform by hand.
Where the risk enters
Watch for four paths:
- a package name that is not declared in the project or lockfile
- a close spelling of a popular package
- an unconstrained version such as 'latest', '*', or '^1.0.0' in a sensitive workflow
- an install script that executes shell commands before review
The Sonatype 2026 State of the Software Supply Chain describes the same pressure from another angle: AI accelerates dependency changes, while generated suggestions can include unsafe or nonexistent packages.
Make dependency decisions reviewable
Start with a lockfile and make changes visible in pull requests. A useful review asks:
1. Does the package have a real maintainer and a history that matches its claimed purpose?
2. Is the exact version recorded in the lockfile?
3. Does the package run a lifecycle script during install?
4. Does the new dependency need network, filesystem, or credential access?
5. Is there a safer platform or standard-library option?
For a quick local baseline:
~~~bash
npx ship-safe@latest audit . --no-ai
npm audit --audit-level=high
~~~
The local scan is useful before a model-assisted review because it checks the repository without sending source code to an AI provider.
Do not let the agent approve its own dependency
An agent can propose a package, edit 'package.json', run the install, and summarize the result. That is a complete change loop with no independent control. Split the responsibilities:
- the agent proposes the dependency and explains why it is needed
- a developer or policy gate approves the package and version
- CI verifies the lockfile, vulnerability status, provenance, and install behavior
- the agent can then update code against the approved dependency
For production projects, use an allowlist for packages that may be introduced automatically. Keep the list short and review changes like code.
What to do about install scripts
Install scripts are not automatically malicious, but they are executable code arriving through a dependency boundary. Review them when a package is new, changes ownership, or gains a surprising capability.
For high-risk environments, install with scripts disabled, inspect the dependency tree, then allow only the scripts required by the build:
~~~bash
npm install --ignore-scripts
npm ls --all
~~~
The exact control depends on the package and build system. The important part is that the exception is deliberate and documented.
A practical policy for AI-generated dependencies
- No dependency is accepted only because a model suggested it.
- Every new package has an exact version and lockfile entry.
- New install scripts require review.
- CI fails on high-severity vulnerabilities unless an exception is documented.
- Package changes are scanned in the same pull request that introduces them.
- Secrets are unavailable to dependency-install jobs for untrusted pull requests.
This is where a security scanner earns its place: not by replacing package review, but by catching the quiet inconsistencies that are easy to miss during a fast AI-assisted change.
Read the Ship Safe dependency and supply-chain docs and use the web app guide when you want scan history and team triage around the same decision.