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:

1. Gate manifest edits separately from code edits. A dependency introduction is a trust decision, not a code change. Route it to a human.
2. Check package age and release count at install time, not audit time. npm audit runs after the postinstall hook already fired.
3. 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.