Coding models hallucinate nonexistent package names predictably (19.7% of code, and 43% of the names repeat), letting an attacker register them first with a malicious payload. The defense: verify that any AI-suggested package exists and is legitimate before installing it.
Picture asking an assistant to grab you a screw from a hardware store, and instead of admitting it doesn't know which one, it invents a brand name that sounds perfectly plausible: "Kraften M8 Screws." You go and ask for it, trusting. And it turns out someone, anticipating that exact invention, has already opened a shop under that name and filled the box with explosives. Move that into software and it's had a name since 2025: slopsquatting. Your AI invents a library that doesn't exist, and an attacker registers it before you do to slip in malicious code. It's the most elegant and silent supply-chain attack vector the era of AI-assisted coding has brought us, and almost nobody on your team knows it exists.
Hallucination stopped being a joke and became an attack surface
For years we treated AI hallucinations as a funny anecdote: the model makes up a quote, a fact, a date. Annoying, but harmless. With code, the hallucination changes its nature. When a model writes `import requestz` instead of `requests`, or invents a `pandas-utils-pro` that never existed, it isn't cracking a joke: it's signing a cheque someone else can cash. Because unlike a fake quote, a package name is an address. And addresses can be claimed. The day the hallucination had a registrable mailing address on npm or PyPI, it stopped being a style slip and became a door.
The hard number: nearly 1 in 5 code snippets suggested a phantom package
A study presented at USENIX Security 2025 measured it at industrial scale: 2.23 million code samples generated by 16 different models. The result is the one you should have taped to your monitor: 19.7% of the samples included at least one hallucinated package — one that simply doesn't exist. And the bias by model family is brutal: open-source models invented packages 21.7% of the time, versus 5.2% for commercial ones. Translated: nearly one in five times a model offers you a dependency, it's offering one that doesn't exist. Multiply that by the millions of `pip install` and `npm install` commands run every day on the blind faith that "if the AI wrote it, it must exist," and you have your attack surface.
The truly dangerous part isn't that it invents: it's that it invents THE SAME THING EVERY TIME
If hallucinations were random noise, the attack would be unworkable: an attacker would have to register millions of random names to hit one. The finding that turns this into a real problem is another: 43% of hallucinated names reappear across every run. It's not noise, it's a signature. Given the same prompt, the model tends to invent the same fake name over and over. That's gold for an attacker: they only need to watch what the model invents, keep the names that repeat, register them with a malicious payload, and wait. They don't need to hack anything. You set the trap for them, and your own agent installs it with your build's permissions. Seth Larson, of the Python Software Foundation, named the pattern: slopsquatting — typosquatting's cousin, but where the mistake isn't made by your finger, it's made by your model.
Why agentic coding multiplies the risk instead of containing it
A human developer who sees `import fastapi-turbo` in a suggestion usually raises an eyebrow: "does that exist?" An autonomous agent doesn't raise eyebrows. You told it "make it work," it trips over a failing import, and its trained reflex is to fix it: it runs the `install`, and if the package exists (because the attacker registered it), it installs it frictionlessly and moves on. The loop that makes agentic coding magical — try, fail, correct, continue — is exactly the one that leaps over the only barrier that protected us: human doubt. The more autonomous the agent, the fewer eyes between the hallucination and the `install`. Autonomy without verification isn't speed, it's speed toward the cliff with the headlights off.
The lesson: in the AI era, trusting a name is a security decision
Here's the mental frame you can take with you and share: a package name suggested by an AI isn't a fact, it's a hypothesis. And any hypothesis about to run code with your build's permissions deserves to be verified before, not after. The concrete action fits in a sentence: before installing any dependency a model suggested, confirm the package really exists, that it's the one you think, and that it wasn't born last week with zero history. A lockfile with pinned hashes, a dependency allowlist, and a two-second glance at "does this package have years and downloads, or did it show up on Tuesday?" fully defuse this attack. You don't need an AI firewall: you need to stop treating the model's output as sacred scripture. The same discipline, incidentally, that separates a demo from a product — which we cover in the math of the 27%.
How we see it
At NeuralOS we start from an uncomfortable axiom: AI is a brilliant collaborator and an occasional liar, and you have to design for both at once. That's why we think of security not as a layer stuck on at the end, but as the ground you build on. Some pieces of that ground are already tangible: secrets are redacted by value in every log, and credentials live in a per-tenant encrypted Vault that's never exposed to the model. Others are stated direction, not delivered promise: in that same spirit we created and gave away Sentinel, an open-source code security guardian that catches the bug before it reaches production. We can't stop a model from hallucinating a name — nobody can, it's the physics of the system. What we do pursue, piece by piece and with honesty about what already exists and what's still road ahead, is to raise the moat between that hallucination and your build: to have the platform hold the doubt that an agent no longer has, on your behalf. Because in the era of building with AI without being a programmer, your edge isn't trusting faster: it's that verification doesn't rest on your good faith alone.