Slopsquatting: The Supply-Chain Attack Your AI Agent Invites In

Part of our AI Code Governance: A 2026 Field Guide series — the operating model for attributing, classifying, deciding, and proving AI-written code.

Your developers ask an AI agent to add a library. It writes the import, adds the dependency, and moves on. The code looks right. The package name looks right. There's just one problem: the package doesn't exist — the agent made it up.

Today that's a broken build. Tomorrow, if an attacker got there first and registered that invented name, it's a backdoor you installed yourself.

That's slopsquatting. And unlike most supply-chain risks, it isn't a hole someone found in your defenses — it's a door your own tools keep opening.

What is slopsquatting?

Slopsquatting is a supply-chain attack in which an attacker registers a package name that an AI coding assistant has hallucinated, so that the next developer whose agent invents the same name unknowingly installs the attacker's code. The name is a portmanteau of "slop" (low-quality AI output) and "typosquatting" — but where typosquatting preys on human typos, slopsquatting preys on machine invention.

The chain is short and entirely plausible:

1.  An AI agent suggests import fastjson-utils — a package that resolves in no registry.

2. The name is not random. Agents hallucinate the same confident-sounding names repeatedly, so the invented name is predictable.

3.  An attacker registers that exact name on PyPI or npm, with a payload.

4. The next agent that invents it — or the developer who copy-pastes the snippet — installs it. No typo, no phishing, no breach required.

Why AI agents manufacture this risk

Older supply-chain attacks needed a human to slip: a mistyped name, a credential leak, a compromised maintainer. Slopsquatting needs none of that. The vulnerability is generated for free, at scale, by the productivity tool you deployed on purpose.

Two things make it worse than a one-off mistake. First, volume: researchers studying AI code assistants have found that a meaningful share of the packages they suggest — in some analyses close to one in five — don't exist in any public registry. Second, repeatability: hallucinations cluster around a stable set of plausible names, which turns "the agent occasionally invents a package" into "attackers can predict the names worth registering." That combination — high volume, low randomness — is exactly the shape of an attack surface, not a fluke.

Why your existing tools wave it through

Here's the uncomfortable part: a hallucinated dependency often passes the checks you already trust.

•  Vulnerability scanners grade packages that exist. A name that resolves in no registry has no CVEs — so it reads as clean, not as suspicious.

•  The build may not fail until deploy, and once the attacker registers the name, it stops failing — the install now succeeds, silently.

•  Code review sees an import that looks entirely normal. Nobody cross-checks forty dependency names against a registry by hand.

The signal isn't missing because your tools are bad. It's missing because "this package name was invented by an agent and matches nothing real" is a question none of them were built to ask.

Catching it: presence is a fact, not an opinion

You don't need a smarter model to grade whether a dependency "looks legitimate." You need to observe a fact: does this package the agent introduced actually resolve to something real?

That's the whole move — and it's why it's defensible. A control that says "No hallucinated dependencies in agent-authored code" turns green because a name was checked against real registries and found (or found missing), never because a language model decided it seemed fine. An observed fact can be sealed into a record, reproduced, and shown to an auditor. An opinion can't.

Keep the intelligence where it belongs — helping you map the control — and keep the verdict deterministic.

What to do this quarter

You can close most of this gap without slowing anyone down:

1. Attribute. Know which dependencies were introduced in AI-authored changes — that's where the invented names concentrate.

2. Verify existence, not just vulnerability. Add a check that every new dependency resolves to a real, established package — treat "resolves to nothing" as a finding in its own right.

3. Pin and lock. Lockfiles and pinned versions blunt the window between "agent invents a name" and "attacker registers it."

4. Record it. Make "no hallucinated dependencies" a live control in your matrix, evidenced continuously — so the answer to "are we exposed to slopsquatting?" is an artifact, not a shrug.

Where Provenance fits

Diwo Provenance governs AI-written code by reading the signals the estate already emits — including the dependencies agents introduce. It flags packages that resolve to nothing real as an observed fact, ties them to the repositories and the AI-authored changes that brought them in, and rolls them into a sealed control record you can hand to a board, an auditor, or a customer's due-diligence team.

Not another scanner shouting about packages that exist. The one check that asks whether the package your agent just added is real at all.

Seeing your own estate takes about 15 minutes with a free, read-only connection: connect your estate free and find out which dependencies in your AI-authored code resolve to nothing real.

Your scanner checks if a package is safe. Provenance checks if it's real.

Related reading

•   The pillar: AI Code Governance: A 2026 Field Guide — the full operating model and the three risks to govern first.

•    Your AI Agent Has Your Production Keys — Here's How to Find Out

•    Who's Accountable When AI Writes the Code?

FAQ

Is slopsquatting the same as typosquatting? No. Typosquatting exploits human typos of real package names. Slopsquatting exploits invented names that AI assistants hallucinate — the developer never mistyped anything.

Is slopsquatting the same as dependency confusion? They're cousins. Dependency confusion exploits how installers resolve names across public and private registries; slopsquatting exploits AI-hallucinated names. Both end the same way: you install code you didn't mean to.

Do I need to scan source code to catch it? No. You need to check the dependency names agents introduce against real registries — a signal about your estate, not a read of your source.

Diwo helps organizations govern AI-written code: attribute it, classify it, decide against your controls, and prove it — as sealed evidence, mapped to the frameworks you already answer to.