Slopsquatting exploits the reproducibility of AI hallucinations. Attackers register packages that models frequently invent, turning statistical noise into a supply chain attack vector. Defence requires mechanical checks, not just better prompts.
The emergence of autonomous coding agents has shifted the threat landscape from human error to systemic predictability. A new attack pattern known as slopsquatting capitalises on the fact that large language models often generate the same incorrect package names when asked to solve similar problems. Unlike traditional typosquatting, which relies on a developer’s momentary lapse in attention, slopsquatting targets a reproducible flaw in the model’s training data and generation logic.
When an agent proposes a dependency that does not exist, it is not merely making a random mistake. It is following a statistical pattern that is consistent across different sessions and users. An attacker can monitor these outputs, identify the most frequently hallucinated names, and register them in public package registries before the legitimate code is ever written. This transforms a software reliability issue into a direct security vulnerability.
The defence against this cannot rely on human vigilance alone. Agents often install dependencies in unattended loops, bypassing the careful scrutiny a human developer would apply. Security teams must implement mechanical controls such as registry allowlists and strict lockfile policies. Without these barriers, the organisation accepts the risk that every generated line of code could introduce a malicious binary.
What slopsquatting is
Slopsquatting concerns the registration of software package names that are commonly hallucinated by artificial intelligence models. The term combines "slop," referring to low-quality or generated content, with "squatter," indicating the act of claiming a name before its intended user. In the context of software development, the target is usually a package name that sounds plausible but has no legitimate owner.
The mechanism differs significantly from traditional typosquatting. Typosquatting exploits human cognitive biases, such as misreading a letter or confusing similar-sounding words. It requires a human to make a mistake at the point of installation. Slopsquatting, by contrast, exploits the predictable recurrence of hallucinated names in model outputs. If a model is prompted to create a database connection helper, it might consistently suggest a package named db-helper-utils or sql-connector-lite, even if those packages do not exist.
Attackers analyse these patterns to build a list of high-probability hallucinations. They then register these names in relevant package repositories. When an AI agent encounters a prompt that triggers this specific hallucination, it attempts to install the package. The agent believes it is fetching a legitimate tool, but it is instead downloading code authored by the squatter.
This approach scales efficiently for attackers. They do not need to wait for a specific developer to make a mistake. They simply wait for the model to make the same mistake repeatedly. The volume of generated code increases the surface area for these attacks. Every new project that uses an AI coding assistant becomes a potential entry point for compromised dependencies.
Why hallucinations are repeatable
The core vulnerability lies in the way language models generate text. They predict the next token based on patterns learned during training. When a model encounters a common coding task, it retrieves the most statistically probable sequence of words. If the training data contains references to non-existent packages or if the model has conflated similar names, it will reproduce that error with high frequency.
This repeatability is not a bug; it is a feature of how these systems work. Consistency is often valued in model outputs to ensure reliability. However, when the underlying data is flawed or incomplete, consistency ensures that the flaw is also reliable. A model might hallucinate a package name once in a thousand prompts, but if it does so consistently across thousands of sessions, the pattern becomes detectable.
Researchers and security practitioners have observed that certain types of packages are more prone to hallucination. Utility libraries, authentication helpers, and data processing tools are frequent targets. The names often follow common naming conventions, using hyphens or underscores to join descriptive words. This makes them look legitimate to both humans and automated scanners.
The predictability allows attackers to pre-emptively register these names. They do not need to guess which specific package a developer will need. They only need to know which packages the model is likely to suggest. This shifts the burden of proof from the attacker to the defender. The defender must now verify that every suggested package is real, rather than assuming that a suggested package is likely real.
From suggestion to install in an agent loop
The danger escalates when AI coding agents operate in autonomous loops. These agents can generate code, propose dependencies, and execute installation commands without human intervention. In this environment, the friction that usually prevents typosquatting is removed. A human developer might pause to check if a package exists on a website. An agent typically does not.
The agent receives a prompt to implement a feature. It generates the code and identifies a missing dependency. It then issues a command to the package manager to install that dependency. If the dependency name was hallucinated, the package manager will either fail or, worse, find a registered package with that name. In the case of slopsquatting, the package exists, but it is malicious.
The agent installs the package and proceeds to build the application. The malicious code is now part of the software supply chain. It may exfiltrate data, inject backdoors, or compromise the build environment. Because the agent operates without supervision, this process can happen in minutes. The organisation may not discover the compromise until the code is deployed or an audit reveals the anomaly.
This automation amplifies the impact of the attack. A single hallucinated package name can be used to compromise hundreds of projects if the agent is configured to install dependencies automatically. The speed of the attack outpaces the ability of security teams to respond. By the time the malicious package is detected, it may have already propagated through multiple systems.
Checks that catch a fake package
Defending against slopsquatting requires moving beyond prompt engineering. Better prompts may reduce the frequency of hallucinations, but they do not eliminate the risk. The defence must be mechanical and enforced at the infrastructure level. The first line of defence is to ensure that the package manager only installs packages from trusted sources.
Registry allowlists are a critical component of this strategy. An allowlist specifies exactly which packages are permitted in the organisation’s codebase. When an agent proposes a new dependency, the system checks it against the allowlist. If the package is not on the list, the installation is blocked. This prevents unknown or hallucinated packages from entering the environment.
Lockfiles provide another layer of protection. A lockfile records the exact versions of all dependencies used in a project. When the agent generates new code, the system verifies that the proposed dependencies match the lockfile. If the agent suggests a new package, the system flags it for review. This ensures that no new dependency lands in the codebase without explicit approval.
These checks must be integrated into the CI/CD pipeline. They should run automatically on every commit. This creates a feedback loop where security is enforced by default. Developers and agents alike must adhere to the same standards. The goal is to minimise the attack surface by ensuring that only verified packages are ever installed. For more on the risks of inheriting unvetted transitive dependencies, see risks of inheriting unvetted transitive dependencies.
Allowlists and lockfiles for agent workflows
Implementing allowlists and lockfiles requires a shift in how organisations manage their dependencies. It is not enough to rely on the agent’s suggestions. The organisation must maintain a curated list of approved packages. This list should be reviewed regularly to ensure it remains relevant. Packages that are no longer used should be removed to reduce the attack surface.
Lockfiles must be version-controlled and treated as source code. Any changes to the lockfile should trigger a security review. This ensures that every new dependency is examined for legitimacy. The review process should include checking the package’s reputation, author, and download history. If the package is new or has no history, it should be rejected.
For agent workflows, this means configuring the agent to respect the allowlist. The agent should be instructed to only propose packages that are on the list. If a required package is not on the list, the agent should flag it for human review. This introduces a necessary friction point that prevents automated errors from becoming security incidents.
It is also important to monitor the registry for new packages that match hallucinated patterns. Security teams should set up alerts for packages that are registered with names similar to common utility libraries. This allows for proactive defence. If a suspicious package is detected, it can be reported to the registry operator and blocked in the allowlist. For details on ensuring integrity of installed packages, see ensuring integrity of installed packages.
What registries could do
Package registries play a vital role in mitigating slopsquatting. They can implement stricter validation rules for new package registrations. For example, they could require proof of ownership for package names that match common patterns. This would make it harder for attackers to register hallucinated names.
Registries could also provide better visibility into package history. They could highlight packages that have been registered recently and have no prior activity. This would help developers and agents identify potentially malicious packages. Registries could also collaborate with AI model providers to share data on common hallucinations.
By sharing this information, registries and model providers can work together to reduce the effectiveness of slopsquatting. Model providers could adjust their training data to avoid generating names that are likely to be squatting targets. Registries could block or flag packages that match known hallucination patterns. This collaborative approach would strengthen the entire software supply chain.
However, registries face challenges in balancing security with openness. Too much friction may discourage legitimate developers from publishing packages. The goal is to find a balance that protects users without hindering innovation. For insights into why an audit or security badge does not guarantee what it seems to.
Questions people ask
What is slopsquatting in software development?
Slopsquatting is an attack where adversaries register package names that are frequently hallucinated by AI models. Unlike typosquatting, which relies on human error, slopsquatting exploits the predictable errors of AI systems. Attackers register these names to intercept automated installations by coding agents.
Can ai coding assistants install malware?
Yes, AI coding assistants can install malware if they are configured to install dependencies automatically. If the assistant hallucinates a package name that has been registered by an attacker, it may download and install malicious code. This risk is heightened when agents operate without human oversight or mechanical checks.
How to check if a package is legitimate?
To check if a package is legitimate, verify its existence in the official registry and check its reputation. Look for the package’s history, author information, and download counts. Use registry allowlists and lockfiles to ensure that only approved packages are installed. If a package is new or has no history, treat it with suspicion and seek human review.
Close
Slopsquatting represents a fundamental shift in how supply chain attacks are conducted. It moves the burden of security from the developer to the infrastructure. As AI coding agents become more autonomous, the risk of automated compromise increases. Organisations must adapt by implementing mechanical controls that enforce security by default.
The defence is not about building better prompts. It is about building better barriers. Allowlists, lockfiles, and registry checks are essential tools in this defence. They ensure that every dependency is verified before it enters the codebase. This approach minimises the risk of hallucinated packages becoming a vector for attack.
The landscape of AI-assisted development is evolving rapidly. Security practices must evolve with it. By recognising the unique risks of slopsquatting, organisations can protect their software supply chain. The goal is to enable innovation without compromising security. This requires a commitment to rigorous, automated verification at every step of the development process.