If I use an AI coding assistant to speed up development, one thing I always keep in mind is that the model can generate code containing libraries that sound legitimate but may not actually exist.

For example, I might ask an AI assistant to help me integrate an API, and it could suggest something like:

from flask_auth_vault import AuthManager

At that point, it can be tempting to immediately run:

pip install flask-auth-vault

But that's exactly where I need to slow down.

If the package doesn't exist, the installation will normally fail. However, if someone has registered that previously nonexistent package name with a malicious implementation, the situation becomes much more dangerous.

This technique is commonly referred to as slopsquatting, where attackers take advantage of package names hallucinated or invented by AI coding assistants.

In this article, I'll explain how the attack works, why AI-generated dependencies need verification, and the practical steps I can take to reduce the risk.

What Is Slopsquatting?

I think of slopsquatting as a variation of the traditional software supply-chain attack.

The difference is where the package name comes from.

With traditional typosquatting, an attacker registers a package name that looks similar to a legitimate package.

For example:

requests
reqeusts

A developer accidentally types the second name and may end up installing a malicious package.

With slopsquatting, the package name can originate from an AI-generated code suggestion.

The basic sequence is:

Developer asks AI for code
          ↓
AI suggests a package
          ↓
Package name doesn't actually exist
          ↓
Attacker registers the name
          ↓
Developer later installs it
          ↓
Malicious code may execute

The important lesson for me is simple:

I should never treat a package name suggested by an AI model as proof that the package is legitimate.

Typosquatting vs Slopsquatting

Attack	How It Starts	Main Dependency
Typosquatting	Developer makes a spelling mistake	Human typing error
Dependency Confusion	Build system selects the wrong package source	Package configuration
Slopsquatting	AI suggests a package name that may not exist	AI-generated dependency

The important difference is that an AI assistant can generate the same plausible-looking package name for multiple developers working on similar problems.

That makes verification particularly important.

How a Slopsquatting Attack Can Happen

I'll use a simplified example to show the workflow.

Step 1: I Ask an AI Assistant for Code

Suppose I ask an AI coding assistant:

“Write a Python example that validates webhook signatures from a cloud storage service.”

The assistant may generate code using a library that sounds reasonable:

import cloud_webhook_verify

def handler(request):
    if not cloud_webhook_verify.validate(request):
        return {"status": "unauthorized"}

    return {"status": "ok"}

The problem is that I don't yet know whether cloud_webhook_verify is a real package.

That's the point where I should verify it.

Step 2: I Search the Package Registry

If the package doesn't exist, I might normally see an error when attempting to install it.

But imagine an attacker notices that AI assistants frequently generate this package name.

The attacker could register a similarly named package on a public package registry.

The malicious package could contain documentation and functions that appear to match the AI-generated code.

From my perspective, the package may initially look legitimate.

Step 3: I Install the Package

I might then run:

pip install cloud-webhook-verify

This is where the supply-chain risk begins.

Python package installation can involve build and installation steps that execute code, depending on the package format, tooling, and build configuration.

That means I shouldn't assume:

“I haven't executed my application yet, so nothing dangerous can happen.”

Installation itself needs to be treated as a security-sensitive operation.

Why AI-Generated Dependencies Need Extra Verification

AI coding assistants are designed to generate plausible code.

They are not package registries.

An AI model may know that a particular type of functionality commonly has libraries associated with it, but that doesn't mean every package name it produces corresponds to a real project.

A package name can look completely reasonable:

azure-webhook-verify
cloud-auth-helper
fast-api-security
aws-session-tools

But a convincing name doesn't tell me:

Who maintains the package
When it was created
Whether it has a legitimate source repository
Whether the package is widely used
Whether its published files match the source code
Whether it contains unexpected installation behavior

That's why I treat the package registry as the source of truth, not the AI-generated code.

Why CVE Scanning Alone Isn't Enough

One common misconception is that a malicious package will automatically have a known CVE.

That's not necessarily the case.

A newly published malicious package may not have a known vulnerability identifier at all.

This creates several potential problems.

1. No Known Vulnerability

A brand-new package may simply have no vulnerability history.

That doesn't mean it's trustworthy.

It only means that there may not yet be a known vulnerability record associated with it.

2. The Package Can Contain Functional Code

A malicious package doesn't have to be completely fake.

An attacker could create code that appears to perform the functionality described in the documentation while also containing unwanted behavior.

3. Malicious Behavior Can Change Over Time

A package may appear harmless initially and later receive an update containing unwanted functionality.

That's why dependency pinning and reviewing updates are important parts of software supply-chain security.

How I Verify an AI-Suggested Package

Before I install an unfamiliar package suggested by an AI assistant, I check the package registry first.

For Python packages, I look at PyPI.

I check:

Package Name

Does the exact package exist?

Maintainer

Who owns and publishes it?

Release History

Does the project have a history of releases?

Source Repository

Does it link to a legitimate repository?

Documentation

Does the documentation actually match what the package claims to do?

Download Activity

Are there signs of genuine usage?

Dependencies

What other packages does it install?

Published Files

Do the package contents make sense for what the library claims to provide?

None of these checks alone proves that a package is safe.

Together, they give me substantially more information than the AI-generated import statement.

Don't Treat Download Counts as a Security Guarantee

Download numbers can be useful context, but I wouldn't use them as a definitive trust signal.

A popular package isn't automatically safe, and a new package isn't automatically malicious.

Instead, I look for a combination of signals:

Package identity
      +
Maintainer history
      +
Source repository
      +
Release history
      +
Dependencies
      +
Published files
      +
Security scanning

The goal is to establish provenance rather than relying on one metric.

Use Dependency Locking

Once I've verified a dependency, I don't want production systems to unexpectedly install a completely different version later.

Dependency lockfiles help make builds reproducible.

Depending on the project, I might use:

requirements.txt
pip-tools
uv.lock
Poetry lockfiles
Another dependency-management system

For example, a pinned dependency might look like:

requests==2.32.5

For stronger supply-chain protection, dependency hashes can also be used where appropriate.

The important idea is:

Don't let production builds blindly resolve arbitrary dependency versions.

Use Package Auditing Tools

I can also scan installed Python dependencies using tools such as pip-audit.

Install it with:

pip install pip-audit

Then run:

pip-audit

This checks installed Python packages against known vulnerability information.

However, I wouldn't treat pip-audit as a complete defense against malicious packages.

A package can be malicious without having a known CVE.

That's why package provenance, code review, dependency controls, and runtime monitoring still matter.

Prefer Trusted Package Sources

For production environments, I prefer to control where dependencies come from.

Organizations can use internal package repositories or artifact proxies to provide developers and CI systems with approved dependencies.

This gives security teams more control over:

Which packages are allowed
Which versions are approved
Which dependencies are cached
Which packages require review
What enters the production environment

This can be especially useful for organizations with strict software supply-chain requirements.

What About `--only-binary :all:`?

You may see recommendations such as:

pip install --only-binary :all: <package>

This tells pip to prefer or require binary distributions rather than building from source for packages where compatible wheels are available.

That can reduce exposure to some source-build scenarios, but I wouldn't describe it as a complete defense against malicious packages.

A malicious wheel can still contain malicious code.

The broader principle is:

Package format is only one part of the security decision.

I still need to verify the package itself.

What I Would Do in a Real Development Workflow

My workflow for an unfamiliar AI-suggested dependency would look something like this:

AI suggests package
        ↓
Search official package registry
        ↓
Does the package actually exist?
        ↓
Check maintainer and repository
        ↓
Review release history
        ↓
Inspect dependencies
        ↓
Run security scanning
        ↓
Pin approved version
        ↓
Install in isolated environment
        ↓
Test before production use

The key change is that I don't copy an AI-generated pip install command directly into a production environment.

I verify it first.

Is Slopsquatting Only a Python Problem?

No.

The same general concept can apply to other package ecosystems.

AI coding assistants can generate dependencies for ecosystems such as:

Python / PyPI
JavaScript / npm
Java / Maven
Rust / crates.io
Go modules
Other public package registries

The exact attack mechanics differ between ecosystems, but the fundamental problem is similar:

An AI-generated dependency name is not automatically a verified dependency.

A Simple Security Checklist

Before installing an unfamiliar package suggested by an AI coding assistant, I ask:

Does the package actually exist?
Is the package name exactly correct?
Is there a legitimate maintainer?
Does it have a source repository?
Does the source repository match the package?
Does the release history make sense?
Are its dependencies expected?
Does the package contain unexpected installation scripts?
Has it been scanned for known vulnerabilities?
Is the version pinned?
Have I tested it in an isolated environment?
Is it approved for production use?

If several answers are unclear, I don't install the package immediately.

The Bigger Problem With AI-Generated Code

Slopsquatting is part of a larger issue with AI-assisted development.

AI coding assistants can generate:

Incorrect APIs
Outdated libraries
Nonexistent functions
Incorrect configuration options
Vulnerable code patterns
Invented package names

The code can look convincing while still being wrong.

That's why I treat AI as a coding assistant rather than an authority.

I still verify:

Libraries
APIs
Versions
Security assumptions
Configuration
Documentation

before relying on generated code in an important project.

Final Thoughts

AI coding assistants have changed how quickly I can build software.

But that speed comes with a new responsibility: I need to verify what the AI gives me.

When an AI assistant suggests an unfamiliar dependency, I don't assume the package exists or that it is trustworthy.

I check the package registry.

I verify the maintainer and source repository.

I review its release history and dependencies.

I scan it for known vulnerabilities.

And once I've approved it, I pin the dependency so future builds are predictable.

The important lesson isn't that AI coding assistants are inherently unsafe.

It's that AI-generated package recommendations should be treated as untrusted suggestions until they're independently verified.

A few seconds of dependency verification can prevent an AI-generated hallucination from becoming a software supply-chain problem.

Slopsquatting: How Malicious PyPI Packages Exploit AI Coding Assistants