Slopsquatting in Agentic Coding: When the AI, Not the Developer, Runs the Install Command

Most explanations of slopsquatting describe the same scene: a developer asks an AI assistant for code, the assistant suggests a package that sounds plausible but doesn’t exist, and an attacker who registered that exact name in advance gets a free install. That scene assumes a human reads the suggestion before anything gets installed. In an agentic coding workflow — a coding agent with shell access that writes code, decides it needs a dependency, and runs the install command itself — that assumption is gone. The hallucinated name goes straight from generation to execution, with no pause where a person could have said “wait, that doesn’t look right.”

This matters because the fix everyone recommends for slopsquatting — “verify the package exists before installing it” — quietly assumes a human is in the loop to do the verifying. Agentic tools remove that human by design. The gap isn’t whether slopsquatting exists (it’s well documented at this point); the gap is what changes when the reviewer step disappears entirely.

Why agents hallucinate package names in the first place

A code-generating model doesn’t look anything up when it writes an import statement or a pip install line. It predicts the next plausible token based on patterns from training data — and a name like fastapi-middleware or aws-helper-sdk is exactly the kind of name that pattern-matches to real conventions without corresponding to any real package. Research published on this (Spracklen et al., presented at USENIX Security) measured hallucination rates in the range of roughly 5% for commercial models and over 20% for some open models, depending on the language and prompt. A later industry analysis from Sonatype in 2026 found a comparable pattern specifically in dependency recommendations from a leading LLM.

The more relevant detail for agentic workflows is repeatability: a separate analysis from the Cloud Security Alliance found that a meaningful share of hallucinated names reappear consistently across repeated runs of the same prompt. That repeatability is what makes the attack economically viable — an attacker doesn’t need to guess at random, they can probe a model the same way a developer would and register whatever comes up reliably.

What’s different when the agent has shell access

In a manual workflow, the chain is: model suggests a package name, developer reads it, developer runs the install command. Every one of those steps is a place where a human might notice something off — an unfamiliar name, a typo-adjacent word, a package with zero GitHub stars. In an agentic workflow using something like an autonomous coding agent with terminal access, the chain collapses to: model decides it needs a package, model runs the install command. There’s no intermediate read step.

This is sometimes called an excessive-agency failure mode: the agent has more autonomy than the trust model around it accounts for. The agent isn’t doing anything different from a model suggesting code in a chat window — the hallucination rate is the same. What’s different is that nothing stands between the hallucination and code execution on a machine or in a CI sandbox. Trend Micro’s 2026 testing of this specific scenario found that reasoning-heavy agents cut phantom package suggestions roughly in half compared to simpler models, and that agents wired up to live registry lookups through MCP got the rate lower still — but none of the configurations they tested eliminated it. A lower rate multiplied across thousands of autonomous agent runs per day, across a fleet of developers, still adds up to a steady stream of opportunities.

A reproducible way to see the pattern yourself

You don’t need a research paper to observe this — you can check it directly against a real package registry. The following script sends a set of dependency-generation prompts to any code-capable LLM API you have access to, extracts the package names it suggests, and checks each one against the real PyPI index. Run it a few times with different prompts and you’ll typically see at least a handful of names that don’t resolve to anything.

import re
import urllib.request
import json

def check_pypi(package_name: str) -> bool:
 """Returns True if the package exists on PyPI."""
 url = f"https://pypi.org/pypi/{package_name}/json"
 try:
 with urllib.request.urlopen(url, timeout=5) as resp:
  return resp.status == 200
 except urllib.error.HTTPError as e:
 if e.code == 404:
  return False
 raise

def extract_package_names(code_text: str) -> list[str]:
 # Matches "pip install x" and "import x" / "from x import"
 installs = re.findall(r"pip install ([a-zA-Z0-9_-]+)", code_text)
 imports = re.findall(r"(?:import|from) ([a-zA-Z0-9_-]+)", code_text)
 return list(set(installs + imports))

def audit_generated_code(code_text: str) -> dict:
 names = extract_package_names(code_text)
 results = {name: check_pypi(name) for name in names}
 hallucinated = [n for n, exists in results.items() if not exists]
 return {"checked": names, "hallucinated": hallucinated}

# Example: paste output from your coding agent/assistant here
sample_output = """
pip install fastapi-middleware
import pandas as pd
from starlette_reverse_proxy import ReverseProxy
"""

print(audit_generated_code(sample_output))

Point this at the raw output of whatever coding agent you’re testing before any install step runs, and you have a cheap trust gate: known-good packages pass through, unknown names get flagged for a human to look at before anything reaches pip or npm. This is the same principle behind purpose-built tools like slopcheck, just reduced to the minimum you’d need to understand the mechanism yourself.

Where this does not help

A registry existence check only catches names that don’t exist at all — it does nothing against an attacker who has already registered a plausible hallucinated name and populated it with working, malicious code. If fastapi-middleware genuinely resolves on PyPI because someone squatted it last month, this check passes it straight through. Existence is not the same as legitimacy, and no amount of “does this name resolve” logic substitutes for checking package age, maintainer history, and download patterns before trusting a first-time dependency.

It also doesn’t help with typosquatting, which is a related but distinct problem: a human or agent correctly recalling a real package name but mistyping it into something an attacker registered deliberately. That’s a spelling-error attack surface, not a hallucination attack surface, and it needs a different defense (name-similarity checks against known-good packages, not existence checks).

Finally, none of this addresses the case where the hallucinated package is internal — an agent operating inside a monorepo hallucinating a plausible-sounding internal module name that happens to collide with something an insider or attacker planted in a private registry. Public-registry checks like the one above are blind to that scenario entirely.

What actually changes the risk for agentic setups specifically

Since the failure mode here is specifically the missing human checkpoint, the fix has to restore a checkpoint somewhere in the pipeline rather than trying to make the model hallucinate less. Three things do that without slowing an agent down to manual-review speed: gate any new (never-before-approved) dependency behind an existence-plus-age check before install, run agents with install permissions scoped to a pre-approved allowlist rather than unrestricted pip/npm access, and log every dependency an agent installs autonomously so a human reviews the diff of “what got added” even if they weren’t in the loop for the individual install. None of these require slowing the agent’s actual coding work — they only add friction at the one step where an unverified name would otherwise become running code.