Dependency control when an agent picks the packages

Most AI code-quality discussion is about the code. The most consequential new risk is about what the code imports.

The measured problem

Researchers from the University of Texas at San Antonio, the University of Oklahoma and Virginia Tech generated 576,000 code samples across 16 models and counted references to packages that do not exist. Commercial models produced references to invented packages in at least 5.2 percent of samples and open-source models in 21.7 percent, yielding 205,474 distinct fake package names [1].

The important part is the repetition. An invented name that appears once is a typo. An invented name that a model produces often for a common prompt is a name anyone can register and fill with their own code. The attack is straightforward: find the names models invent, register them, publish something that runs on install, and wait for an agent to add it to somebody's build.

This is already happening in the wider world of open-source packages. In September 2025 a self-replicating worm spread through npm using stolen maintainer credentials, and CISA published an alert on 23 September 2025 advising organisations to review dependencies, pin npm packages to releases produced before 16 September 2025, rotate developer credentials immediately, and mandate phishing-resistant multifactor authentication on developer accounts [3]. OWASP's Top 10:2025 lists Software Supply Chain Failures as A03 [2].

Why AI-native teams are more exposed

Three reasons, all structural rather than about any particular tool.

Volume. More changes means more opportunities to add a dependency, and each one is a small decision nobody flagged.

Plausibility. A suggested package name usually looks right. It follows the naming conventions of the package registry, it is descriptive, and it appears in code that otherwise works. Nothing about the diff signals that this line is different from the twenty around it.

Convenience bias. An agent solving a problem will use a library, because that is what the training data does. Left alone it will add three dependencies where a human would have written fifteen lines, and every one of them is a permanent obligation. Our post on the cost of a dependency you did not choose covers the long-run version of this cost.

The policy

Five rules, all enforceable.

A new dependency is its own change. Not part of a feature branch. Its own diff, its own review, one line explaining why it is needed and what was considered instead. This single rule catches most of the problem, because it makes the decision visible at the moment it is made.

The package must exist and be the one you think it is. Verify the registry entry, the repository behind it, the maintainer, and the download history. A package with a plausible name, no history, and a recent first publish is the exact profile of a slopsquat: a fake package registered under a name that models invent.

Lockfiles are authoritative and pinned. Builds resolve from the lockfile, not from a range. This is what makes a compromise investigable later, and it is the specific control CISA recommended during the npm incident [3].

Advisory checks block the merge. A known vulnerable version does not reach the main branch, and the check runs in the pipeline rather than as a report someone reads weekly.

Install-time scripts are treated as execution. Anything that runs during install is running on a developer machine and in continuous integration with whatever credentials are there. If your package manager allows it, disable install scripts by default and allow them per package.

Where the check has to live

In the pipeline, as a gate. Not in a linter that warns, not in a weekly report, and not in a policy document.

The reason is timing. A dependency added at ten in the morning is depended upon by three other changes by the afternoon, and the cost of removing it rises with every hour. The check that matters runs on the change that adds it, and it fails the build.

There is a second requirement that teams miss: the check must run on changes made by agents in exactly the same way as on changes made by people, with no fast path. If an automated pipeline can add a dependency without the gate, the gate does nothing.

Adding fewer packages instead of checking more of them

The cheapest dependency is the one you did not add. Two habits make a measurable difference.

First, tell the agent what it may use. A short list of approved libraries for common jobs, in the repository where the model reads it, stops most of the invented names. Agents follow explicit conventions well when the conventions are written down where they load them, which is the practical point of documentation an agent and a new hire can use.

Second, ask for the version without the library for small jobs. A date formatting helper, a debounce, an argument parser: these are often twenty lines, and twenty lines you own are cheaper over five years than a dependency with its own release cycle, its own maintainer risk, and its own chain of indirect dependencies.

Read the lockfile diff, not just the manifest

A change that adds one package usually adds more than one package. The manifest shows the decision; the lockfile shows the consequence, and the consequence is where the risk is.

Make the lockfile diff part of what a reviewer sees. The questions are simple: how many packages arrived, does any of them have a name that looks close to a well-known one, and is anything appearing here that is unrelated to the stated purpose of the change. A change described as adding a date library that pulls in thirty transitive packages including a network client is worth thirty seconds of attention.

This is also the practical answer to typo-style attacks, which are an older problem related to invented package names. A name one character away from a package with millions of downloads is hard to see in a manifest and obvious in a diff when you are looking for it.

Internal packages need the same rules

Teams often apply dependency policy to the public registry and skip it for their own internal packages, on the reasoning that internal code is trusted. That reasoning fails against this attack.

An internal registry is a smaller, more valuable target: it is the one place where a single compromised credential reaches every service in the company, and internal packages usually run install scripts that nobody has read in years. The controls that matter are the same ones, applied to internal packages. Publishing requires more than one credential. Package names are reserved so an internal name cannot be claimed on the public registry, which is what makes a dependency confusion attack possible in the first place. And the resolution order is explicit, so a public package can never replace an internal one of the same name.

None of this is new advice. What is new is the volume of dependency decisions being made per week, which is what turns a policy gap that used to be theoretical into one that attackers actually use.

What to do if you find one

Assume credentials were exposed. That is the standard assumption after any suspicious install-time execution, and it is what CISA recommended during the npm incident: rotate developer credentials immediately, and audit repository webhooks, secrets and installed applications [3].

Then find out how far it spread. The lockfile history tells you when it entered and which builds included it, which is the reason for the pinning rule above. Check the machines as well as the repositories: a package with an install script has run on every developer machine and every build agent that installed it, so the question is not only which services released it but which environments executed it.

Then remove it, rebuild, and write the postmortem in a way that names the missing control rather than the person who approved the change. Our post on how to handle a security finding in generated code covers the sequence.

Where this connects

This is one of the five gates in the quality gates that should block a merge, and it is an architectural decision in the sense used in the decisions that stay with your engineers, since a dependency is expensive to reverse once other code depends on it. The broader question of whether generated code is secure is covered in is AI-generated code secure. The main guide puts it in the context of the whole delivery model.