The AI Supply Chain

1You execute far more third-party code than your own

A modest application has a handful of direct dependencies and several hundred transitive ones. The ratio of code you reviewed to code you run is not close.

This was already the largest attack surface most applications have, and it has three properties that make it awkward: you did not choose most of it, it updates without you asking, and a package can run code at install time — before any of your tests, linters or scanners see it.

What has changed is the selection step. Deciding which package to add used to involve a person searching, reading a README, glancing at the download count, and typing the name. Now a suggestion arrives inside a working diff, the name is plausible, the code around it compiles, and the path of least resistance is to accept. The review question has quietly shifted from “is this code correct?” to “where did this dependency come from?” — and the second question is much less often asked.

2Package hallucination and slopsquatting

A model asked for code will sometimes import a package that does not exist. The name is plausible, the usage is idiomatic, and the package has never been published by anyone.

This is measurable, and it has been measured. A 2024–25 study across 16 models and roughly 576,000 generated code samples found that about 19.7% of recommended packages did not exist. Commercial models performed several times better than open ones on this metric — the strongest were around 5% — which is an improvement rather than a solution, because one in twenty is still a lot of suggestions when a team accepts hundreds a week.

On its own that is an annoyance: the install fails and somebody fixes the import. The attack is the second step, and it is called slopsquatting: hallucinated names are not random. The same models suggest the same plausible names repeatedly, so an attacker can collect them, register them on a public registry, and wait for the installs to arrive.

Why this is more efficient than typosquatting is worth stating precisely. A typosquatter needs a victim to make a specific mistake, and most people do not. A slopsquatter needs a model to make a mistake it makes reliably, on request, at scale — and the resulting name arrives inside a working code sample that looks authoritative, so it carries more credibility than a typo does. The attacker’s hit rate is not a function of human carelessness; it is a function of a system’s reproducible behaviour.

The control is unglamorous and effective: verify the package exists and is what it claims before installing it, and let nothing install straight from a generated diff. That means a lockfile that is reviewed, an install step that fails on an unknown name rather than reaching out to a public registry, and a human looking at the dependency change specifically — which is the subject of the next section.

3Reviewing what an agent added, not what it wrote

Code review evolved to catch logic errors written by colleagues. The failure mode of generated code is different, and review has not caught up.

Generated code is usually locally correct. It compiles, it passes the tests, the naming is reasonable and the structure is idiomatic — which is precisely why reviewing it the traditional way, by reading it for mistakes, finds so little. The risk has moved to what the change brings with it.

The most useful practical change is to read the lockfile diff first, before the code. It is short, it is mechanical, and it is where the highest-severity surprises are — a two-line feature that adds forty transitive packages is a fact about the change that the code itself does not show you. Reading it first also protects you from the ordering effect: after twenty minutes of reading plausible code, a new entry in a lockfile does not get the attention it would have got cold.

The second change is to review the deletions with more suspicion than the additions. An agent asked to make a test pass may weaken the test; asked to clean up a module it may remove the deliberate oddity from Chapter 16; asked to simplify a handler it may drop the ownership check from Chapter 19. All three read as tidying, and all three are the diff getting smaller in the place where it should not.

4Prompt injection when the agent holds real tools

A model cannot reliably distinguish instructions from you and instructions embedded in content it was asked to read. That is not a bug to be patched; it is a property of how the input is processed.

The OWASP Top 10 for LLM Applications ranks prompt injection first, and the reason is the combination rather than the technique. A model that only produces text can be tricked into producing bad text, which is a quality problem. A model that holds a database credential, a payment API key and a shell can be tricked into doing something, and that is a security problem with the same blast radius as the credentials you gave it.

The mechanism is simple enough to state in a sentence: everything the model sees is one stream, and text you fetched sits in that stream next to your own instructions. A web page, a support ticket, an invoice description, a code comment, a README in a dependency — each is a place an attacker can write, and each arrives as text the model treats the same way it treats you.

Which produces the two rules everything else follows from:

1. Fetched content is data, never instruction. Delimit it, label it, and say in the system prompt that instructions inside it are to be reported rather than followed. This helps and is not a guarantee — which is why it is rule one of two rather than the answer.
2. The agent’s authority is what actually bounds the damage. If a compromised agent cannot send money, delete data, or reach the internal network, then a successful injection produces a wrong answer instead of an incident. Every control worth having is a version of this.

5Controls that actually work

Four controls, in descending order of how much they help. The first two are architectural and the second two are habits, and the ordering is not the one most teams start with.

The ordering is the argument. Most teams reach for the fourth row first, because it is a prompt change and prompts feel like the place where model behaviour is decided. It helps, and it is the weakest control on the list, because it depends on the model doing the right thing with adversarial input — which is precisely the assumption you cannot make. The first two rows work regardless of what the model decides, which is the property that makes a control a control.

The clean way to say it: design so that a fully compromised agent produces a bad answer rather than a bad action. If you cannot arrange that, the remaining authority is what needs a human in front of it.

6Build: the dependency and agent policy for Ledger

One page, enforced where possible, and short enough that people have read it.

Dependencies. Six rules, four of them automated:

1. A new direct dependency requires a one-line justification in the pull request — what it does and what the alternative was. Enforced by a check that fails when the manifest changed and no justification is present.
2. A build fails when a newly-added package has no registry history or was published within 30 days, unless a reviewer overrides it explicitly.
3. Install scripts are disabled by default; enabling one for a specific package is a decision with a name attached.
4. The lockfile is reviewed as its own artefact, first, before the code.
5. Internal package names are scoped, and the registry configuration never falls back to public.
6. Dependency updates land on a schedule with a delay, so a compromised release is not adopted within hours of publication.

Agents. Four rules, all structural:

1. Credentials are scoped to the task and read-only unless the task genuinely writes. The drafting agent cannot issue an invoice, and the code agent cannot reach production.
2. Tools are allowlisted per task. Adding a tool to a task is a change somebody reviews, not a configuration default.
3. Anything that spends money, sends a message to a customer, deletes data or changes a permission requires a human confirmation — and the confirmation shows what will happen, not just that something will.
4. Fetched and retrieved content is delimited and labelled as untrusted, and the system prompt says that instructions found inside it are to be reported rather than followed.

Notice which of these are enforced by a machine and which rely on a person. Four of the six dependency rules are build checks, and every one of the agent rules is structural — because a policy that depends on somebody remembering under deadline is the one that fails on the day it matters, which is Chapter 16’s argument arriving in a different chapter.

✓Checkpoint

▶Playground

More payloads, and the same four controls. Try to find a combination that stops every one of them — and notice which single control does the most work.

✓Exercise set

Twelve problems, most of them the checks this chapter argues should run automatically: a lockfile differ, a package-risk scorer, an install-script detector, a tool allowlist, a capability scoper. Each is short, and each closes a class of failure. Your work is saved in this browser.