Your AI agent installed dozens of packages you never picked. Should you care?

Mik Bry · 2026-08-25 · ~9 min read · KB · Launch Readiness

Every time your AI coding tool adds a login form, a PDF export, a payment button, it will often rely on packages other developers already published rather than writing that code from scratch. That's a dependency. It can quickly mean dozens of direct packages and many more transitive ones.

That, by itself, isn't unusual. Most modern applications rely heavily on third-party packages. What's different with an agent is the review step. A human developer may pause to look at who maintains a package, how widely it's used, or whether it's still active. With an agent, that decision can happen as part of solving the immediate task without any explicit review. That's what "unreviewed" means here — not that the code is bad, but that nobody ever made that call.

01 — What is it?

Think of your app's dependencies as ingredients you buy, not ones you grow. A restaurant kitchen doesn't farm its own flour or churn its own butter — it orders ingredients from suppliers it trusts, and a good kitchen still checks what shows up in the delivery before it goes anywhere near a dish. Your app works the same way: almost nothing is grown from scratch, and code you didn't write is not automatically code that's fine to use unchecked.

There are two layers to this, and the second one is the part most founders never hear named. Direct dependencies are the packages your agent explicitly added — the ones that would show up if you asked it to list what your project depends on. Transitive dependencies are everything those packages need in turn, pulled in automatically, several layers deep, that nobody explicitly chose at any point. A project with twenty direct dependencies can easily carry several hundred transitive ones underneath — invisible unless something goes looking.

Either layer can enter the project without a separate moment where someone explicitly reviews the choice. That's the gap this article is about.

02 — Why should you care if you don't code?

Because this is a recognized category of real-world failure, not a fringe concern. OWASP's 2025 Top 10 — the closest thing security has to a shared list of "these are the ways applications actually get broken into" — renamed and broadened what used to be a narrower 2021 category ("Vulnerable and Outdated Components"). A03:2025 Software Supply Chain Failures is one of the OWASP Top 10 categories. The 2021 name is worth knowing only as history at this point; it's not the current framing.

Source: OWASP Top 10:2025, category A03 — Software Supply Chain Failures, owasp.org/Top10. Cited here as the current framing; A06:2021 Vulnerable and Outdated Components is its historical predecessor, not a separate current category.

There's also a risk specific to AI-assisted coding that didn't exist before agents started writing install commands on their own: slopsquatting. An AI model, asked to solve a problem, will sometimes confidently suggest a package name that sounds exactly right and doesn't exist — because the name is plausible, not because it's real. If an attacker notices which invented names models keep suggesting and registers those names first, the next agent that "helpfully" installs the package is installing whatever the attacker put there.

This isn't hypothetical. In January 2026, a security researcher at Aikido found a package called react-codeshift — a name no human ever registered, invented by an AI mashing together two real, unrelated packages (jscodeshift and react-codemod) into something that merely sounded plausible. The hallucinated name had already spread to 237 repositories through AI-generated coding-agent instructions, copied and forked without anyone checking whether the package was real, and kept receiving live install attempts from agents even after the researcher claimed the name defensively to keep an attacker from getting there first. Nobody planted this — one AI invented a name, and other AIs kept trying to install it.

Source: Aikido Security, "Slopsquatting: The AI Package Hallucination Attack Already Happening," aikido.dev/blog.

Worth noting separately, so the two don't get conflated: a different September 2025 incident, a self-replicating worm named Shai-Hulud, compromised hundreds of real npm packages by phishing a maintainer's credentials — not by inventing a name. Different mechanism, same lesson: something already in your dependency tree can turn hostile without anyone choosing anything.

Source: Unit 42 (Palo Alto Networks), "'Shai-Hulud' Worm Compromises npm Ecosystem in Supply Chain Attack," unit42.paloaltonetworks.com.

03 — What does good look like?

You don't need to read a line of code to check most of this. Look for:

• Direct dependencies you can actually name — not "ask the agent, it knows," but a list that exists somewhere and that you, or your agent on your behalf, can point to.
• A lockfile committed alongside the code — package-lock.json, pnpm-lock.yaml, yarn.lock or the equivalent — records the resolved dependency versions so installs are much more reproducible across machines and deployments.
• A rough sense of whether each direct package is still alive — who maintains it, and roughly when it was last released. Ingredients age like milk, not like salt: a package nobody has touched in years isn't automatically broken, but it's also not getting security fixes if something is found wrong with it.
• The OWASP A03:2025 framing in mind, not as jargon — "dependency policy unclear" isn't a pedantic finding. It's naming an OWASP Top 10 category of real breaches.

Sources: npm Docs — package-locks, on what a lockfile actually pins; Snyk — managing open source dependencies, on treating dependencies as an ongoing responsibility rather than a one-time choice.

None of this requires becoming the person who reviews every package by hand. It requires knowing the list exists, and asking the two or three questions above about what's on it — which is exactly what the prompt below does for you.

04 — What can you safely ask your AI agent?

You don't need to inspect any of this yourself. Ask your AI coding tool to check it for you — and don't let it guess. A search that can't verify something is not the same claim as a package that's confirmed clean; if your agent can't check a given package against real registry data, the honest answer is "I couldn't verify this," not a guess dressed up as an answer. Paste this in as-is:

Read what comes back before you act on any of it. A list of named direct dependencies, each with a verifiable last-release date and a clear "no advisory found" or "couldn't verify" next to it, is what good looks like from section 3, confirmed. A vague summary, or an agent that quietly updates something while it's "just checking," is your actual starting point — worth understanding before you build another week on top of it.

This is one article in the Launch Readiness KB series that walks through what a Trust Report scan actually looks for before you launch, hire, or raise on an AI-built app — one concept per article, always ending in something safe to ask your agent, never something that changes your code.