Slopsquatting Is Not a Hallucination Problem

The framing you'll see in most security writeups goes like this: AI models hallucinate package names, attackers register those names, developers get compromised. The implied fix is obvious — improve the models, reduce hallucinations, problem shrinks.

The Attack Doesn't Need Hallucinations to Be Frequent. It Needs Them to Be Consistent.

If LLMs hallucinated package names randomly — different names each time, different across models — slopsquatting would be operationally worthless. You can't pre-register a package name you can't predict.

The problem is that LLM hallucinations are structurally deterministic. A model generating code for JWT validation in a Python service will consistently produce something like jwt-http-parser or python-jwt-utils because those tokens are high-probability completions given that context. Run the same prompt across a hundred sessions, two model versions, five different users — the same phantom names surface repeatedly. The model isn't guessing. It's interpolating from training patterns, and the interpolation is stable.

This means the attacker's workflow is just a data collection problem: run common coding prompts at scale, collect package names that appear in generated code but don't exist in the registry, register them. The entire attack is front-loaded. After registration, it's passive. The victims come to the pre-positioned payload.

Improving models reduces the rate of hallucination. It does nothing about the phantom packages already registered against the hallucinations from previous model versions. The attack surface accumulates faster than it can be cleaned up.

Package Selection Became an Implicit Decision

Every supply chain security control in existence — lockfile pinning, dependency review gates, vulnerability scanning, license checks — was designed around one assumption: a human developer made a deliberate selection decision at the keyboard.

That assumption is no longer valid.

When a developer accepts an AI code suggestion, they are evaluating logic flow, naming, structure. They are not perceiving themselves as selecting a dependency. The package name is incidental to the thing they're actually reviewing. The trust decision happened upstream, inside a model that has no access to the registry it is implicitly referencing.

Slopsquatting doesn't break the security controls. It routes around them entirely by moving the dependency selection decision to a place those controls don't reach.

This is structurally different from typosquatting, where the error happens exactly where defenses are positioned — at the moment of installation. Typosquatting is a precision attack on a known decision point. Slopsquatting eliminates the decision point.

The Defense Is in the Wrong Place

The immediate instinct is to fix this at the AI assistant layer — prompt the model to verify package existence, add retrieval against a registry snapshot, fine-tune on real package names. These interventions address a symptom (the hallucination) without addressing the structural gap (the missing verification step between generation and installation).

The registry lookup that should happen at generation time isn't the AI assistant's responsibility to perform. It doesn't have live registry access, and adding it creates its own attack surface (stale snapshots, poisoned retrieval results). More importantly, putting the verification inside the model means trusting the model to catch its own errors — which is not how you build reliable systems.

The correct intervention point is the gap between code generation and code execution: the moment a package name moves from an AI suggestion into a pip install or npm install. That gap exists in the developer's workflow, in the IDE plugin, and in the CI pipeline. It is not a model problem. It is a toolchain problem.

Concretely: any tool that wraps or intercepts AI code generation — IDE assistants, MCP servers, CI validators — can perform a registry existence check on every package name before it surfaces to the developer. This is cheap (a single HTTP call per package name), deterministic, and catches the attack before the install happens. It also doesn't require model cooperation.

The teams shipping AI coding tooling that don't have this check are not missing a security feature. They are missing the recognition that they now own a step in the dependency selection process that used to belong entirely to the developer.

What Engineers Should Actually Do

The organizational response is simpler than most security guidance makes it sound. You have one structural gap to close: the dependency governance process that assumes a human made a deliberate selection needs to be extended to cover selections that AI made on the human's behalf.

In practice:

• Any new package appearing in AI-generated code gets treated as unverified until a registry existence check passes and a lockfile entry is explicitly reviewed.
• CI pipelines should diff the dependency manifest against the previous committed state and flag net-new additions. This is a two-line change that catches every dependency injection attack, not just slopsquatting.
• If you're building or evaluating AI coding tooling, the presence or absence of a pre-suggestion registry existence check is a meaningful signal about whether the tool has thought seriously about its position in the supply chain.

The vulnerability isn't in the model. It's in the assumption that the security perimeter you built for human-authored code still holds when the code author is a system that has never seen your registry.