I build with AI almost every day. I have used Claude Code, Codex, GitHub Copilot, Cursor, and Antigravity across different projects, and lately I have been paying more attention to how much we allow these tools to do on our behalf.
They are already well past autocomplete. An agent can inspect a codebase, decide how to implement a feature, install a dependency, run commands, fix whatever breaks, and keep going until the tests pass.
I like that because it saves me a lot of time. But as agents get more autonomy, a wrong dependency can become a security problem too.
For years, one way attackers took advantage of package ecosystems was typosquatting. Hackers published something close enough to a popular dependency, hoped somebody ran npm install or pip install with the wrong name, and waited.
Slopsquatting gives them another route. The developer does not even have to mistype the package name. The model can make one up.
Say an agent decides it needs a package while working on your code. The name sounds right, the API it generates around it looks reasonable, and the install command works exactly like every other command you see during development.
npm install some-perfectly-reasonable-package
Except the package name came from the model.
If nobody owns that name yet, the installation fails, and the mistake is easy to spot. If someone has registered the hallucinated name first, the installation succeeds.
That is where this gets interesting.
Some of these package names are predictable
For slopsquatting to be useful as an attack, models need to generate believable package names with some degree of consistency.
There is evidence that they do. Researchers presenting at USENIX Security 2025 generated 576,000 Python and JavaScript code samples across 16 models and looked for packages that did not exist. They found an average hallucination rate of at least 5.2% for commercial models and 21.7% for open-source models, with 205,474 unique nonexistent package names across the experiment.
Around 45% of the hallucinated packages were generated every time the researchers repeated the same prompt. About 60% appeared again at least once across ten subsequent prompts.
That changes the risk because a random package name that appears once is mostly noise, but a package name that a model keeps inventing for the same kind of task gives an attacker something they can predict and register.
In January 2026, Aikido security researcher Charlie Eriksen found references to an npm package called react-codeshift.
The name sounds completely normal because jscodeshift is real, and so is react-codemod. react-codeshift sounds like another tool from the same ecosystem, except it was completely made up.
By the time Eriksen found it, 237 GitHub repositories were already referencing the package and instructing AI agents to run it. He traced the references back to LLM-generated agent skills that had been copied, forked, reorganized, and even translated.
He registered the package defensively before someone else could and then started seeing download attempts.
That part is worth sitting with for a moment… lmao!
The hallucination had moved out of a model response and into repositories that other agents could read later.
Agents make the failure easier to execute
A few years ago, using an AI assistant often looked something like this:
There was still room to make a bad decision, but a person normally saw the package name before anything happened.
An agent can compress that flow:
That is useful and also exposes a different security model since the same system that proposes the dependency can now install and execute it.
This matters even more with agent instructions.
The react-codeshift example spread through skill files, which are mostly Markdown and other text that looks harmless when you browse a repository. To an agent, a command inside that file can be something to execute.
A line like:
npx react-codeshift
has a different meaning when the thing reading the file has shell access.
I think we are going to have to get more comfortable treating some of these files as part of the executable surface of a project. If an AGENTS.md, skill, README, or setup document contains commands that an agent will follow automatically, reviewing those commands matters just as much as reviewing the code they eventually produce.
The agent does not care that the instruction came from Markdown.
Checking that the package exists only helps at first
One obvious response to slopsquatting is to make agents verify every package against npm or PyPI before installing it.
But… the problem is that slopsquatting works by changing that answer. Once an attacker claims the hallucinated name, there really is a package under that name now.
So I think there are two separate questions whenever an agent introduces a dependency:
Does this package exist?
and
Do I trust the code behind this package?
The first question is cheap to automate. The second needs more information.
Where is the source repository? Who owns it? How long has the package existed? Does the registry metadata point to the repository you expect? What does it execute during installation? Is there any reason this project needs that dependency in the first place?
Package registries are giving us more information here. npm supports trusted publishing through OpenID Connect, and supported workflows can publish provenance attestations showing where and how a package was built.
PyPI supports digital attestations too, which can tie a release to a specific publishing identity such as a GitHub Actions workflow.
Those are useful signals because they let us verify where an artifact came from.
PyPI's own security documentation makes an important point, though: an attestation tells you where a package came from, but you still have to decide whether you trust that identity.
That distinction matters here. Someone can create a repository, configure CI, publish a package correctly, and end up with valid provenance. The provenance can prove that the package really came from that repository.
You still need to decide whether that repository should be entering your project.
I would put the boundary around new dependencies
I use coding agents because I want them to work. Having to approve every file edit, shell command, and test run would remove a lot of the benefit. But I sometimes prefer that route.
A new dependency feels like a useful place to draw a different line.
If an agent uses a library that is already in my lockfile, there is usually nothing unusual about that.
If it introduces a package the project has never used before, I want to know.
Before all the steps in the image above, I will add one question:
Do we need another package at all?
AI tools can reach for dependencies very quickly. Sometimes that is exactly what I want. I am not going to ask an agent to reimplement a mature parser, database driver, or cryptography library to save one entry in package.json.
But every dependency adds code maintained outside the project and gives that code some level of access to our development, build, or runtime environment.
The nice thing is that the agent can do a lot of this work too. Before adding a dependency, it can check the registry, inspect the source repository, look at release history, check for provenance, inspect installation scripts, and explain why it chose that package.
Then I am reviewing a decision with evidence instead of finding a mystery package in the lockfile later.
That seems like a better use of AI than letting the first plausible package name it generates become part of the project.
I expect agents to keep getting more autonomous. But I am becoming more careful about the point where that autonomy brings someone else's code into the project.
