DEV Community: Khushi Trivedi

When AI Agent adds Package, Who Approves That Dependency?

Khushi Trivedi — Mon, 02 Nov 2026 23:30:44 +0000

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!❤️

The 60-Second Check Before Every npm install

Khushi Trivedi — Mon, 19 Oct 2026 15:32:41 +0000

One wrong package name can run attacker code on your laptop or CI

Honestly, I'd say npm install is the riskiest five seconds of your day now that typosqatting is so common. It's the potential moment a attacker's code gets a chance to run on your laptop or your CI runner.

This is not theoretical anymore. It has happened several time, at a huge scale! Some incide

In 2017, The Slovak National Security Office flagged ten fake Python packages. One fake package was urllib,instead of urllib3.
They also collected the system's data! news link
npm's official record listed 13 releases of a fake package called crossenv for the real pkg cross-env. Funfact if you today run npm view crossenv, it returns 0.0.2-security. This is apparantly a placeholder npm put in its place.
19.7% AI generated code samples had package names that doesn't exist. Yes, in 2025 USENIX Security study checked 2.23 million AI-generated code samples. If I were an atatcker, I'd register those names and wait. This is called slopsquatting.

After reading about these attacks, I'd the first thing is to have my own investigation. Here are my findings. Enjoy the blog further:

How to confirm a package is the one you meant, step by step

This is for developers, SREs, DevOps engineers, and the people who review their pull requests. Run these before you add a package you have not used before:

1. Exact spelling and ecosystem
Read the name letter by letter against the project's own docs. Then ask the registry if it exists.

npm view cross-env name version
python3 -m pip index versions requests

*A missing name returns E404 on npm, or No matching distribution found on pip. *

2. Publisher and repo link
Check who owns the package. Then check where it says its code lives.

npm view cross-env maintainers repository.url
# maintainers = 'kentcdodds <me@kentcdodds.com>'
# repository.url = 'git+https://github.com/kentcdodds/cross-env.git'

curl -s https://pypi.org/pypi/requests/json | python3 -c "import sys,json; i=json.load(sys.stdin)['info']; print(i['version'], i['project_urls'])"

** 3. The Package age and publish history **

You can use this to check about the package's record-

npm view cross-env time.created time.modified
# time.created = '2015-10-01T23:19:27.453Z'

npm view cross-env time

curl -s https://pypi.org/pypi/requests/json | python3 -c "import sys,json; r=json.load(sys.stdin)['releases']; print(min(f['upload_time_iso_8601'] for v in r.values() for f in v))"

The red flags would be spotted if: (a) it's been created recently, but has a famous name (b)there's a new maintainer on an old package.

4. Weekly downloads vs. the real project
Another interesting thing that you can do while patrolling is to compare the lookalike with the project it resembles.

curl -s https://api.npmjs.org/downloads/point/last-week/cross-env
curl -s https://pypistats.org/api/packages/requests/recent

Low count, new package => normal.
Low count, fake package for a famous name => suspicious.

For your example: pypistats excludes known mirrors and updates once a day. (Ref: PyPI Stats API)

5. Install scripts
Here's my observation. Many legitimate packages have a script. I understood this from the hidden install scripts are how the September 2025 Shai-Hulud worm ran its code.

npm view esbuild scripts.postinstall
# node install.js

6. Lockfile diff
One new dependency can pull in many. As a developer, you must never skip reading what changed.

git diff origin/main -- package-lock.json

# only new install scripts
git diff origin/main -- package-lock.json | grep -E '^\+.*"hasInstallScript"'

# for a version bump, see what changed in the code
npm diff --diff=pkg@1.0.0 --diff=pkg@1.0.1 --diff-name-only

Look for names you did not expect, and any added "hasInstallScript": true. For Python, do the same with git diff requirements.txt. npm diff docs

What are the limitations for these six checks

They're merely the checks, but do not really make any install "safe". These are the following limitations:

• A real package published by a real maintainer whose account was compromised will pass all six checks.
• A lockfile poisoned before anyone noticed will look normal in a diff.
• Malicious code that lives in a package's runtime JavaScript, not in an install script, is not stopped by ignore-scripts.

Additional Resouces

I came across this blog- What Is Typosquatting? Attacks, Examples, and AI Risks. by CleanStart.

In this, you can checkout the for the org-level version of this checklist.

It's also my first blog here. Please share your love in comments!❤️