Slopsquatting: When AI Agents Install Fake Packages

Q: What is slopsquatting and how is it different from typosquatting?

Slopsquatting is a supply-chain attack that exploits the tendency of language models to hallucinate package names — inventing plausible-sounding libraries that do not exist. The attacker queries models for common programming tasks, collects the fabricated package names that come back, registers those exact names on npm or PyPI, and waits for the next AI coding agent to confidently install the package it just imagined. The critical difference from typosquatting is the origin of the name. Typosquatting registers misspellings of real, popular packages — a character transposed, a hyphen added — betting that a human will mistype. Because those names are close in edit distance to legitimate packages, defences can detect them: scan for names within one or two characters of a popular package and flag them. Slopsquatted names are not misspellings at all. They are names that never existed in any form until the attacker created them, and they often look entirely reasonable because the model generated them by pattern-matching against thousands of real package names. There is no legitimate package to compare against, so edit-distance detection finds nothing. What makes the attack economical is that hallucination is systematic rather than random: research on package hallucination in code-generating models established that models repeat the same invented names across queries, which means an attacker can harvest a reliable list rather than guessing. The defence therefore cannot be name-similarity analysis. It has to be verification at the point of installation — does this package actually exist with a real history, a resolvable source repository, meaningful download volume, and ideally verifiable build provenance — because the only reliable signal is that a slopsquatted package is new and hollow, not that its name looks wrong.

Q: Why are AI coding agents more vulnerable to this than human developers?

Three structural differences, and the middle one is the actual vulnerability. First, provenance of the name: a human developer gets a package name from somewhere — documentation, a search result, a blog post, a colleague — so the name has at least weak provenance before it is ever typed. An agent can produce a package name from nothing but statistical association, having seen thousands of imports and generating one that fits the pattern. That name may be real, or it may be a name so plausible that an attacker predicted it too. Second, the absence of a reputational instinct: an experienced developer who lands on a package page with twelve stars, one commit, and no README feels something is wrong and investigates. That reaction is social and contextual, and agents have no affordance for it — an unfamiliar package is not a signal they possess, so they resolve and install without the pause that catches the attack. Third, volume and attention: agents add dependencies at a rate no human matches, dozens per session across many repositories, and each addition is buried inside a larger diff. A new dependency line inside a 400-line agent-generated change receives roughly the review attention its line count suggests, which is approximately none. This is the verification bottleneck in its sharpest form — generation capacity is unbounded while review capacity is fixed, so the checkpoint that would have caught the bad package is exactly the checkpoint that got skipped. None of this is a failure of the model behaving badly; the agent did what it was asked. It is a failure of pipeline design: there was no gate between a dependency being named and that dependency being installed, and with human developers that gate was implicit in their hesitation rather than enforced anywhere in the system.

Q: How does a malicious package actually cause damage if my code never calls it?

Because it does not need to be called — both npm and Python execute code at install time, before anything imports the package. In the npm ecosystem, `postinstall` (and related lifecycle scripts) run automatically when a package is installed. In Python, `setup.py` executes during installation of a source distribution. This means the moment your build runs an install, arbitrary attacker-controlled code executes inside your CI runner, with whatever privileges that runner holds. In a typical setup that is a registry publishing token, cloud credentials, environment variables containing API keys, and a full checkout of your source. So the realistic window between "the agent installed something" and "an attacker has your CI secrets and your source" is a single build — which is why detection-after-the-fact is not a viable strategy for this class of attack and why the controls have to be preventive. Two mitigations follow directly and are among the highest-return changes available. First, disable install-time script execution by default: `npm ci --ignore-scripts` and equivalents, with an explicit allowlist for the small number of packages that genuinely require build steps. This single change removes the most common payload path even when a bad package does get past your other defences, and most dependency trees function fine without it. Second, treat the build runner as untrusted execution: run dependency installation in a sandboxed environment with scoped, short-lived credentials, so that if a postinstall does fire, it finds tokens that expire in minutes and permissions that reach nothing important. The combination means a slopsquatted package that slips through becomes a contained incident rather than a credential breach, which is the difference that matters most in practice.

Q: What controls actually stop slopsquatting in a build pipeline?

Gate at the point of installation, because you cannot stop a model from hallucinating a name and should not try — the control belongs where verification is mechanical. Five layers, roughly in order of return. Allowlist agent-initiated dependencies: agents may use packages already in your lockfile or on an approved list, and any genuinely new dependency requires human approval. This is less restrictive than it sounds, because agents rarely need a new library, and when they do that is exactly the moment a person should look. Enforce it in CI rather than in a prompt — a prompt instruction is a suggestion the model may ignore, a failing build is a control it cannot. Disable install-time scripts by default with a small reviewed allowlist, which removes the most common payload path. Verify package characteristics before install: minimum age, minimum download volume, a resolvable source repository, and a maintainer with other work — a package registered eleven days ago with four downloads and no repo is categorically different from one with a decade of history, and OpenSSF Scorecard automates much of this signal. Require build provenance where the ecosystem supports it: npm provenance statements, Sigstore signing, and SLSA build levels let you verify a package was built from the source repository it claims by a build system rather than someone laptop; coverage is uneven so treat it as a strong positive signal and a hard requirement only on sensitive paths. Finally, enforce lockfiles with hashes and use reproducible installs (`npm ci`, not `npm install`) so the build cannot silently resolve to something new. Wrap all of it with scoped short-lived build credentials so the worst case stays survivable, and ship the whole set by default on your platform golden path so individual teams do not have to remember any of it.

Q: Should I review lockfile diffs in code review?

Yes, and most teams have this exactly backwards — they scrutinise code diffs carefully and skip lockfile diffs entirely, when a lockfile entry can execute arbitrary code on the build machine and a code diff generally cannot. A new entry in a lockfile is a supply-chain decision: you are adding a third party to your trusted computing base, granting them install-time execution in CI, and inheriting their transitive dependencies and their maintainers. That is a larger security decision than most of the code changes reviewed alongside it, and it is usually approved without anyone reading it, partly because lockfile diffs are large, noisy, and machine-generated, which trains reviewers to collapse them. The practical fix is not "read the whole lockfile" — that is unreasonable and will not happen. It is to surface new dependencies as their own distinct review artefact: a short automated comment or check that lists packages newly added by this change, along with the signals that matter (age, download volume, whether a source repository resolves, whether provenance is available, and whether a human or an agent introduced it). That turns an unreadable diff into a handful of reviewable facts. In the AI-agent era this matters more, for a specific reason: a dependency added inside a large agent-generated change is invisible in a way it was not when a human deliberately typed the install command, so the deliberateness that used to be implicit now has to be recreated by tooling. Teams that make dependency additions visible in review report the same experience — the number of new dependencies drops, not because anything is forbidden, but because someone is finally looking, and a surprising share of additions turn out to be unnecessary once anyone asks.

Q: Does using an SBOM protect against slopsquatting?

An SBOM helps you respond but does not prevent the attack, and conflating the two is a common and costly mistake. A software bill of materials is an inventory: it records what is in your build, at what versions, with what transitive dependencies. That is genuinely valuable — when a malicious package is disclosed, an accurate SBOM tells you in minutes whether you are affected and where, instead of the multi-day scramble that organisations without one experience. It is the difference between a targeted response and an exhaustive audit. But an SBOM is generated from what you installed, which means by the time a slopsquatted package appears in it, it has already been installed and its install-time scripts have already executed in your CI. The inventory documents the compromise; it does not stop it. Prevention has to happen earlier in the sequence, at the moment the dependency is resolved and installed — which is where the allowlist, the age and provenance checks, the disabled install scripts, and the enforced lockfile do their work. The right mental model is that these are complementary controls at different stages: preventive controls (gate the install) reduce the chance a bad package enters, and detective and responsive controls (SBOM, dependency scanning, provenance records) reduce the time and cost when one does. Both are worth having, and neither substitutes for the other. Where an SBOM does contribute preventively is indirectly: maintaining one forces you to know your dependency surface, which surfaces the packages nobody can justify, and organisations that generate SBOMs seriously tend to also have the lockfile discipline and review habits that block the attack in the first place. Build the SBOM — and do not mistake it for a gate.

Q: Should we just stop letting AI agents add dependencies?

Close to it, and the restriction costs far less than people expect. The pragmatic default that works: agents may freely use packages already present in your lockfile or on an approved list, and adding a genuinely new dependency requires a human decision. In practice, agents rarely need a library the project does not already have — most agent-generated code composes existing dependencies — so the gate fires infrequently, and when it does fire it is fairly precisely the moment a human should be looking anyway. You are not slowing the agent down on the common path; you are inserting judgment at the one step that carries supply-chain risk. Two implementation notes matter. Enforce it in CI, not in the prompt: telling an agent "only use well-known packages" is advice it may or may not follow, while a build check that fails on an unapproved lockfile entry is deterministic. And make the approval path fast — if adding a legitimate dependency takes three days of ticket time, developers and agents will find ways around the gate, and you will have recreated the platform-adoption failure where the compliant path is slower than the workaround. A same-day review with the relevant signals surfaced automatically (age, downloads, repository, provenance) keeps the gate honest without making it an obstacle. The broader framing is that this is an authorisation question, not a capability question: agents are extremely useful and should write code freely, but the set of actions with blast radius beyond the repository — installing third-party code that executes in CI, touching credentials, deploying — is exactly the set that should require explicit authority. Dependency addition belongs on that list, and treating it as routine is how a hallucinated package name becomes a credential breach one build later.

Q: How do I know if my organisation is already exposed?

Answer five concrete questions, and any "no" is an exposure you can close this week. First: can an AI coding agent add a dependency that reaches your build without a human explicitly approving it? For most organisations that have enabled agents, the answer is yes, and that single fact is the core exposure. Second: do install-time scripts run in your CI? Check whether your pipeline uses plain `npm install` (which runs lifecycle scripts) rather than `npm ci --ignore-scripts` with an explicit allowlist — if scripts run, a malicious package has arbitrary code execution in your build the moment it lands. Third: what credentials does your build runner hold, and how long do they live? Long-lived cloud credentials or registry publishing tokens in a runner that executes third-party install scripts is the combination that turns an incident into a breach; scoped, short-lived credentials contain it. Fourth: does anyone actually review lockfile diffs? If new dependencies enter without a named person having looked, the review control you believe you have does not exist. Fifth: do you have an accurate inventory of what is installed, so that when a malicious package is disclosed you can answer "are we affected" in minutes rather than days? The practical audit takes an afternoon: pull the last month of merged pull requests, identify every lockfile change, determine which were introduced by an agent, and check how many received explicit human review of the dependency itself rather than of the surrounding code. The number is usually close to zero, and seeing it is what motivates the fix. Then close the gaps in order of return — disable install scripts, scope build credentials, enforce reproducible installs, add the new-dependency gate — because the first two are configuration changes that can land the same day and remove most of the realistic damage.