AI supply chain risks: understanding slopsquatting

AI coding assistants have crossed from novelty to default faster than most security review processes can catch up. The velocity is real and worth celebrating. The review gap is also real and worth closing.

That gap is exactly what slopsquatting was built for. Supply-chain security researchers at Socket document the pattern on their research blog, which tracks the vulnerabilities that actually matter in AI-accelerated development — including what happens when autonomous agents operate without guardrails (Socket research blog, autonomous agents coverage).

What slopsquatting actually is

Slopsquatting is a supply chain attack where an adversary pre-registers package names that AI coding models are statistically likely to hallucinate. Not typos. Hallucinations — names that look correct enough that the model states them with confidence, plausible enough that a human reviewer skims past them, and almost certainly did not exist when the assistant was trained.

// What the assistant suggests
import { normalizeUrl } from "hhtp-until-utils"

// What the developer thinks they got:
// a plausible npm package name, plausibly scoped, plausibly typed

// What actually sits at hhtp-until-utils:
// a package the attacker registered last week

The economics are asymmetric. The defender has to get every dependency right, every time. The attacker has to register one package the model happens to suggest and wait. When an AI assistant ships hundreds of suggested imports per session, the expected number of hallucinations that land in a codebase is non-trivial.

The mechanism is straightforward: the model was trained on code that references packages, some of which never existed or have since been removed. When it generates an import, it reproduces a name from that distribution. The attacker, knowing which names models tend to invent, registers them first. The install succeeds. The code runs. The payload runs with it.

Slopsquatting vs typosquatting: not the same game

These get conflated because both involve "wrong package names." They are different attacks against different surfaces.

The distinction that matters operationally: typosquatting is a human-error problem you fix with IDE muscle memory and a linter. Slopsquatting is a probabilistic-AI problem you fix at the registry, not in your head. No amount of careful typing prevents a model from confidently suggesting a package that does not exist yet — and no amount of careful reading reliably catches a name that looks exactly like the thousand legitimate names around it. If your team ships AI-assisted code, the AI app security checklist is the companion read for hardening the rest of the surface.

The defenses that actually work

Registry and supply-chain vendors converge on three layered controls. None is novel on its own. The combination is what closes the window.

1. Cooldown policies

A cooldown is a simple rule: a package younger than some threshold cannot be installed into a protected environment. Slopsquatting depends on the attacker registering the hallucinated name after the model was trained but before the developer runs the install. A cooldown forces the attacker to squat the name months in advance, which collapses the economics of the attack.

# Cooldown policy shape (registries vary in syntax)
policy:
  minimum_age_days: 30   # tune to your risk tolerance
  enforcement: block
  scope: production

The primitive is universal: "no package under N days old leaves the boundary." The number is yours to set.

2. Malicious package detection

Static checks catch typosquats. They do not catch a clean, fresh package that does exactly what its name promises and one other thing on top. Malicious-package detection is the layer that looks at behavior — postinstall scripts, network calls, entropy of bundled binaries, package metadata that does not match the source repo. This is one place AI is genuinely useful on the defender's side: flagging the package whose postinstall forks to an unknown endpoint is exactly the kind of pattern a model can learn. Socket's research output is a good ongoing feed for what these malicious packages look like in practice (Socket research blog).

3. Registry-level controls

This is the leg that matters most. As agents take on more autonomous tasks, registry policy becomes the only chokepoint with teeth. The agent does not have judgment. The registry does, if you configure it.

If the policy lives only on the developer's laptop, it does not exist for the agent that runs unattended in CI at 3 a.m. The registry is the one place the rule runs the same for every consumer, human or otherwise. A readable repository structure with pinned, audited dependencies makes these controls enforceable instead of aspirational.

Agentic systems make this worse, not better

This is the part that should hit hardest for anyone shipping with Cursor, Copilot Workspace, or any tool that executes shell commands on the model's behalf. The whole point of an agentic system is to remove the human review moment. The agent does not stop to ask. It runs the install, it imports the package, it moves on — which is precisely the scenario supply-chain researchers warn about when autonomous agents escape their guardrails (Socket on agent escape).

The fix is not "add a human back into the loop" — that defeats the agent. The fix is explicit guardrails, configured once, that the agent cannot talk its way around:

• A private registry as the only allowed source for the agent's installs.
• A cooldown policy applied at the registry, not on the developer's machine.
• An allowlist of vetted packages, or at minimum a denylist of fresh ones.
• A pre-deploy hook that scans the dependency tree before the build proceeds.
• Cursor rules that constrain what the agent may install, so policy lives in the repo and not just in someone's head.

If the agent can reach the public registry directly, the registry-level control is a suggestion. If the agent can only reach your private registry, it is a wall.

The part that does not change when the model does

Here is where this gets durable. The model will change. Copilot will be replaced. Cursor will be replaced. The agentic loop will be reinvented several more times. None of that changes the underlying fact: a component that looks and behaves the same on web, iOS, and Android — one API, one source of truth — collapses the number of novel dependency decisions the AI ever has to make on your behalf. The same Button ships on every platform. It pulls from a curated, pinned package you already audited. There is no hallucinated import for the model to invent, because the import was never a decision the model had to make.

That is the durable layer. When the model hallucinates an import, you want it to land somewhere you have already audited — a curated component package, a pinned version, a registry that has already applied the cooldown and the malicious-package scan. The AI is not the surface you patch. The supply chain underneath the AI is. Build that once, and every model that comes through inherits the controls.

What to do this week

Three moves, in order of cost:

1. Turn on cooldown policies for any production registry you operate. Even a short window cuts the attacker's slack. A longer one kills most opportunistic slopsquatting.
2. Run a malicious-package scan against your current dependency tree. You are not looking for known CVEs here. You are looking for postinstall scripts and outbound network calls that should not exist.
3. Audit every agentic path that can reach a public package registry. If the answer is "yes, the agent can pull whatever it wants from anywhere," the registry policy is still a suggestion — not yet a wall.

AI-assisted velocity is a good thing. It means more developers shipping faster than at any point in the history of the craft. It also means the supply chain attack surface is wider than it has ever been. The answer is not to slow the AI down. The answer is to harden the layer underneath it, so the AI can move as fast as it wants and still land somewhere safe.

Ready to ship AI-assisted code on a hardened foundation? Start from production-tested templates at https://otf-kit.dev/templates — pinned dependencies, audited structure, and security checklists built in.

Sources

• Socket research blog — supply chain security research index
• Socket — when autonomous agents escape, why guardrails matter