Slopsquatting: Your Coding Agent Is a Supply-Chain Attack Vector (and How We Gate It)

There's a category of supply-chain attack that only exists because of AI coding agents, and it has one of the better names in security: slopsquatting. The mechanic takes one paragraph to explain.

Large language models hallucinate package names. Not randomly - consistently. Ask enough models to scaffold a FastAPI service and a measurable fraction will import helper packages that don't exist, and the same phantom names recur across models and prompts.

Attackers noticed. They harvest commonly hallucinated names, register them on npm and PyPI with malicious install hooks, and wait. The next time an agent hallucinates that package, npm install doesn't fail - it succeeds, and the attacker's postinstall script runs with whatever credentials your dev machine or CI runner holds.

Why this defeats code review

Every classic review signal is green. The import statement is idiomatic. The package resolves. The lockfile updates cleanly. There is no suspicious diff hunk to squint at, because the malicious code isn't in the diff - it's on the registry, behind a name the model made up.

The question a reviewer would need to ask is not "is this code correct?" but "why did this dependency appear, and did a human decide to trust it?" That's a provenance question, and diffs don't carry provenance.

Typosquatting is the same problem with an older pedigree - crossenv vs cross-env, reqeusts vs requests - and agents make it worse, because an LLM generating a package name token-by-token is exactly the kind of writer that produces near-miss strings at scale.

How LineageLens Trellis gates this

LineageLens Trellis is a governed runner for AI coding agents (Claude Code, Codex CLI, Gemini CLI, OpenCode) - it correlates what the model claimed to do (proxy traffic), what actually changed on disk (content hashes), and what persisted into git, into one record per edit. That correlation layer is what makes dependency gating more than a linter.

When an agent edit touches a manifest (package.json, requirements.txt, lockfiles), the supply-chain guardrail in packages/core runs two independent checks:

1. Registry verification (online). Does the package exist? How old is it? How many releases, how many maintainers? A package registered eleven days ago with one release and a postinstall hook, introduced by an agent rather than a human, is a fundamentally different risk object than lodash. Hallucinated-but-unregistered names fail outright - the best possible outcome, because you caught the hallucination before an attacker registered it.

2. Edit-distance typosquat detection (offline). Every introduced name is compared against a corpus of high-download known packages. Small Levenshtein distance to a popular package + the popular package not being the one imported = flag. This check is deliberately offline: it must work in air-gapped CI, add zero network latency to the hot path, and never leak your dependency graph to a third-party API.

agent edit → manifest touched?
├─ yes → registry check ──┐
│        edit-distance ───┼→ risk event (attributed to
│        check (offline)  │   session + prompt + tool-call)
│                        └→ pre-commit hook blocks if risky
└─ no → normal provenance pipeline

Because the flag lands in the same provenance timeline as everything else, the alert isn't "suspicious package somewhere in the repo." It's "session #47, running Codex CLI, prompted to 'add retry logic', attempted to introduce requets at 14:32, blocked at pre-commit." Attribution turns an incident into a two-minute investigation.

The practical takeaway

Even if you never touch our tool, do these three things if agents write code in your org:

• Gate manifest edits separately from code edits. A dependency introduction is a trust decision, not a code change. Route it to a human.
• Check package age and release count at install time, not audit time. npm audit runs after the postinstall hook already fired.
• Record which agent/prompt introduced each dependency. When (not if) something gets flagged, attribution is the difference between an afternoon and a week.

Trellis is open source - the detection lives in packages/core/src/dependencies.ts if you want to read or steal the heuristics: https://github.com/karnati-praveen/lineagelens. Deeper dive into the design tradeoffs (why offline, why edit distance over ML classifiers) is on my Hashnode: [Hashnode link].

Question for the comments: if you run coding agents in CI today, does anything stand between the agent and npm install? I'm collecting real-world setups - most answers I've heard so far are "nothing, honestly."