AI Hallucinated Packages and Slopsquatting: How to Stay Safe

AI Hallucinated Packages and Slopsquatting: How to Stay Safe

Yes, AI assistants sometimes suggest packages that do not exist, because they generate plausible-sounding names without checking the official registry. The risk, often called slopsquatting, is that someone registers that name with malicious code, and the next person who installs the suggestion receives the attack. The defense takes discipline, not sophisticated tools: no dependency suggested by AI enters the project until you have verified that it exists, where it comes from and whether you really need it.

Key takeaways

• Language models produce likely text, not verified text. A package name can look right and not exist.
• If the name does not exist, anyone can create it in the public registry. An attacker only has to guess which names the AI tends to invent.
• Packages can run code at install time, so the damage can happen before any test runs.
• Verification fits into a few minutes: confirm existence, history, repository, maintainers and necessity, and only then install.
• Team rules (a lockfile, review of dependency changes, a list of approved packages) reduce risk more than relying on individual attention.

Why does AI suggest packages that do not exist?

A language model completes patterns. When you ask for an integration with a given service in Python or JavaScript, it combines what it has learned about naming conventions: common prefixes, suffixes such as "client", "sdk" or "utils", and the brand name. The result is often a name that fits the ecosystem but was never published.

This is not a rare flaw of one specific model. It follows from how generation works, so it is worth treating as expected behavior, not as an accident. The OWASP list of risks for applications built on language models includes supply chain weaknesses and overreliance on incorrect outputs, and this problem sits exactly where the two meet.

The same applies to versions and functions. The AI may point to a version that was never released or a method the real package does not have. A package existing does not prove the suggestion is right, but a package that does not exist yet is the most dangerous case.

How does an invented name become an attack?

In broad terms, the mechanism has four steps. Note: what follows describes the mechanism in general terms, as a plausible threat model, not as an account of a specific incident.

• Someone asks AI models how to solve common programming tasks and writes down the package names that do not exist in public registries.
• That person registers the most recurring names in the public registry (npm, PyPI and similar), often with a convincing description.
• The package contains malicious code, which can run during installation or be imported later by the project.
• A developer, or a coding agent that installs dependencies on its own, receives the same AI suggestion, runs the install command and brings the package into the company.

The critical point is that the name now exists. The most obvious check, "does the package exist?", is no longer enough. Before registration, the command would fail with a package-not-found error and warn the user. After registration, the installation works and everything looks fine.

Two related problems deserve a place on your radar. The first is typosquatting, which exploits typing mistakes in the names of real packages. The second is dependency confusion, where a company's internal package name is also published in the public registry. The controls below help in all three cases.

Which signs show that a package is suspicious?

No single sign proves a package is malicious, and legitimate new packages exist too. But a combination of several is a reason to stop before installing:

• A very recent creation date compared with the job the package claims to do.
• Few published versions, a single maintainer and no visible usage history.
• No link to a code repository, or a link that points to a project unrelated to the package.
• Generic, copied or nearly empty documentation.
• A name almost identical to a well-known package, with a swapped letter or an extra suffix.
• Install or post-install scripts with no reasonable explanation for what the package does.
• A mismatch between what the AI described (functions, examples) and what the real documentation shows.

For the business side, the practical reading is this: the more a package looks newly created, empty and impossible to trace, the less it deserves a place in a system that touches customer data.

Step-by-step: how to verify a dependency before installing it

This checklist works for anyone who builds software in the company, including people who use AI to generate code without a technical background. It does not replace a formal security review, but it removes most of the risk from invented packages.

• Stop before running anything. Copy the package name from the AI answer, but do not run the install command yet.
• Confirm in the official registry. Search for the name directly on the registry website (npm or PyPI, for example), not through a link the AI provided.
• Look for the source in the service's documentation. If the package claims to integrate a third-party tool, open that tool's official documentation and see which library it recommends. If the AI's name does not appear there, be suspicious.
• Check the history. Look at the creation date, number of versions, latest updates, maintainers and whether the code repository is linked and active.
• Read what runs on install. Check whether there are install or post-install scripts and what they do. If you do not understand them, ask someone in security or development to review.
• Ask whether you really need it. Often the function can be done with the language's standard library or with a dependency the project already uses.
• Install in an isolated environment. Use a container or a disposable machine with no credentials before bringing the dependency into the main project.
• Record the decision. Pin the version in the lockfile and note why the dependency was added and who approved it.

If the package fails any of these steps, the right answer is not to install it and to go back to the AI with a better question, for example: "which official library from vendor X does this, with a link to the documentation?". Then confirm the link on your own.

Illustrative scenario: the integration that "already had a library"

Illustrative scenario: a mid-sized company wants to send order data from an internal system to a payments platform. An analyst with no security training asks an AI assistant for the integration code. The answer includes a well-written example that starts by installing a package named after the platform followed by "helper".

The analyst runs the command and the installation works. The code seems to run in local tests, and the team moves on. Some time later, a dependency review notices that the package does not appear in the platform's official documentation, has a single maintainer and was created close to the date of the company's first use.

The problem was not a lack of skill. It was the absence of a simple rule: a new dependency requires verification at the official source and approval from a second person. With that rule, the analyst would have found the library actually maintained by the vendor in the platform's documentation, and the invented package would never have come in.

Which rules should the team adopt so safety does not depend on each person's attention?

Manual verification works, but it is tiring and fails on a busy day. Process rules carry part of the weight:

• Keep a versioned lockfile and install from it in production and in continuous integration, so nobody installs versions different from the approved ones.
• Require review for every change to dependency files, such as package.json, requirements or equivalents, with the same care given to new code.
• Keep a short list of approved packages for recurring tasks and consult it before asking the AI for suggestions.
• Use the dependency audit tools of your ecosystem to warn about known vulnerabilities. They help, but they do not detect a new, freshly published malicious package.
• Consider an internal package mirror or proxy, when the scale of the team justifies it, to control where dependencies come from.
• Define in a written policy what can be done with AI assistants on company code. The article on a company policy for employee ChatGPT use helps organize that conversation.

Extra care is needed when a coding agent installs dependencies on its own. In that case, limit what the agent can run, require human approval for install commands and run it in an environment with no access to secrets. Permissions for tools and connected servers can be set by scope, as the guide to configuring MCP in Claude Code shows. External text the agent reads can also try to push it into installing something, a topic covered in prompt injection protection for AI agents.

Another useful habit is not to treat generated code as reviewed code. Tests help, but only if they are trustworthy, which the piece on AI-generated tests explores. A passing test does not prove the dependency is legitimate.

How to apply the map, limit, pilot and hand over method

The method we use in AI projects fits this risk well, without requiring anything special. First, map: find out where AI already writes or suggests code in the company, which package registries are used and who can install dependencies. Then, limit: define a list of approved packages, mandatory review of dependency files and an isolated environment for testing.

Next, pilot: apply the verification checklist to one real project, observe what got stuck and adjust. Finally, hand over: give the team the documented rule with a named owner, and decide whether to expand, adjust or stop. The NIST AI Risk Management Framework offers useful vocabulary for that documentation, even if the company does not adopt the framework in full.

Frequently asked questions

Does AI always invent packages? No. In many cases it suggests real, popular packages, but there is no way to know in advance when it will be wrong. That is why verification should be routine, not a reaction to a suspicion.

Is it enough for the package to exist in the registry to be safe? No. Existing only shows that someone published the name, and the attack described here depends on exactly that. Confirm the origin in the service's documentation, the package history, the repository and the install scripts.

Does antivirus or an automated audit solve this? It helps, but it is not enough. Audit tools usually flag already known vulnerabilities and may not recognize a freshly published malicious package. They work best combined with human review and a lockfile.

What should we do if we already installed a package we cannot verify? Treat it as a potential incident. Remove the dependency, review what was executed in that environment, rotate any credentials that were exposed and consult whoever handles security. If personal data is involved, work with your data protection officer to assess obligations under LGPD and the guidance of ANPD, Brazil's data protection authority.

Sources

• OWASP: Top 10 for LLM Applications
• NIST: AI Risk Management Framework
• ANPD: Autoridade Nacional de Proteção de Dados