When AI Agent adds Package, Who Approves That Dependency?

The review meeting started the way they all do: a timeline on the screen and a question nobody wanted. Who approved that dependency? We traced the package back through git blame to a pull request titled "Add retry logic." An AI coding agent had written it, a teammate had skimmed it, and the approval said "LGTM." The code change was forty lines. The lockfile diff underneath it was longer than the code, and one new package sat in the middle of it.

Nobody had been careless in the way we usually mean. The author was a tool, the reviewer read the logic, and the dependency arrived as a side effect. That is the gap this post is about. Our process had a place for approving code and no place for approving a decision to trust a stranger's package.

AI-generated dependency changes slip through because they are small, noisy and trusted

Three habits make them easy to miss. Reviewers read the logic and scroll past manifests and lockfiles, which are long and machine-shaped. Agents tend to make many small dependency edits, and a commenter in a Reddit thread on dependency checking said the risk is highest exactly there, where humans skim. And agents can install packages themselves: Aikido notes autonomous installs, such as in bypass modes or CI with broad npm permissions, skip the human check) that autonomous installs, such as in bypass modes or CI with broad npm permissions, skip the human check entirely.

The result is a quiet shift in who makes the trust decision. It used to be a person typing npm install and thinking about it for a moment. Now it can be a model, a diff and a rubber stamp.

Here's an interesting short-video I found:

The research shows assistants invent packages often enough to matter

A study of 576,000 code samples across 16 models found that 19.7% of recommended packages did not exist, and 43% of the hallucinated names reappeared in every one of ten reruns. This is based on this blogpost that I came across. A name that repeats is a name an attacker can plan around. Bar Lanyado of Lasso Securityregistered an empty package under a hallucinated name and watched it collect more than 30,000 downloads in three months.

Agent workflows add a twist. The name react-codeshift first appeared in one commit of 47 LLM-generated agent skills and spread to 237 repositories before a researcher claimed it. To be fair, those experiments were benign and I know of no confirmed in-the-wild attack of this kind. But a review process that cannot catch a harmless invented name will not catch a hostile one either.

Governance means making the dependency decision a named, required, automated step. This is how it's done:

1. Start with ownership.

A CODEOWNERS file automatically requests review from the right people when a pull request touches their files, and patterns like **/package.json and *.lock can route every manifest and lockfile change to a platform or security team. Then make that review mandatory. In branch protection, you can require pull requests, require approvals, dismiss approvals when new commits are pushed, and require review from code owners. The stale-approval setting matters for agents, because an approval given before the agent pushed a new commit cannot quietly cover a dependency added afterwards.

2. Automate the Evidence:

GitHub's dependency review shows added, removed and updated dependencies on the pull request, including indirect ones from lockfiles, along with release dates. The dependency review action fails by default on known vulnerabilities, and you can make it a required check. Be clear about its limit: a brand-new squatted package has no advisory yet, so a human still has to read the release date and ask why the package exists.

3. Puposely enable Cooldown Option:

For instance, Dependabot's cooldown option basically delays version updates by a configurable number of days (3 by default if you set it without a value), and security updates bypass it. Treat agent-initiated installs as privileged actions, and consider a mirror or allowlist so only vetted packages are reachable, as Seth Larson has suggested for PyPI.

What's in it for the reviewers?

Well, the reviewers should treat every new dependency as its own decision, with its own answers.

When a pull request touches a manifest, we now stop reviewing the code and review the choice. Who suggested this package, a person or the assistant, and why do we need it at all? Does the name match the install command in the project's own documentation? Who publishes it, how old is it, and does the linked repository belong to the real project? Does it run scripts at install time? And does the lockfile diff contain only the packages we expect, or did a single addition pull in a long tail?

A Reddit commenter offered advice that fits perfectly here: run the checking tool right after an agent changes dependencies, before install or merge, and combine signals such as name distance, package age and maintainer changes rather than trusting one. If the answers are thin, the pull request waits.

What's in it for the template writers here?

Template writers should ask for a justification, and advisory readers should trace who added the package

If you own the pull request template, add a short section for dependencies: each new package, its registry link, why it is needed, and whether an assistant suggested it. That turns a silent side effect into a sentence someone has to write and someone else has to read. It also gives incident reviews like ours an answer to "who approved that?" in the first minute.

If you read advisories, the same trail helps in reverse. When an advisory names a package, search your lockfile history and pull requests to see when it arrived, who added it, and through which path, direct or transitive. Remember too that Dependabot's cooldown applies to version updates, not security updates, so an urgent fix can still arrive immediately and deserves a faster, but still human, review.

The End Goal is a Paper Trail for Every Dependency

Our next review went differently. The agent proposed a package, the template asked why, a code owner looked at the release date and the publisher, and the dependency review check showed the lockfile change in plain sight. Someone's name was on the approval, with a reason next to it. Nothing about that slowed us down by more than a few minutes.

If you want a wider view: of why vetting matters before any of this, CleanStart's primer on typosquatting attacks, examples and AI risks notes that OWASP recommends verifying AI-suggested dependencies rather than accepting them at face value.

Hope your enjoyed reading!❤️