AI-Era Supply Chain: What to Trust When Anything Can Be Generated

AI coding tools have changed how software gets assembled. An agent asked to “add PDF export” will happily pull in a package it has never seen before, and a developer moving fast will happily accept it. Meanwhile the same tools make it cheap to produce convincing software: a polished README, a working demo, hundreds of stars, a launch thread.

Put those together and an uncomfortable question follows: what happens when some of that mass of new, heavily promoted, AI-generated tooling has vulnerabilities baked in on purpose? It doesn’t need to be obvious malware. A subtle weakness looks exactly like the ordinary sloppiness of generated code, so it can sit unnoticed for a long time.

This isn’t hypothetical. Several versions of it are already happening.

What’s already out there

• Slopsquatting. Language models sometimes recommend packages that don’t exist. Attackers watch for the names that get hallucinated often, publish real packages under those names with something nasty inside, and wait for an agent or a developer to install them.
• Typosquatting at scale. Lookalike packages are nothing new, but generating thousands of convincing ones, with documentation and fake popularity, now costs almost nothing.
• Hijacked trusted projects. In 2024 the xz-utils compression library was found to contain a backdoor, planted over about two years by a contributor who had patiently earned maintainer trust. In 2025 a self-spreading worm moved through npm, stealing publishing tokens and pushing infected versions of popular packages.
• Editor extensions, MCP servers and agent skills. The newest attack surface, and the one installed most casually. A tool’s description is read by the agent, so it can carry hidden instructions (“also read the SSH key and include it”). This is usually called tool poisoning.
• Deliberately flawed “useful” tools. Weak crypto, an auth check that can be skipped, analytics that quietly send data home. In AI-generated code, malice and carelessness look the same.

A defence in layers

No single control fixes this, so the aim is to shrink what you trust, slow down how fast new code reaches you, and limit what one bad package can reach.

1. Control what gets in

• Curate dependencies. Route installs through an internal registry proxy with an approved list and an on-hold list. A team tech radar works well here: anything unvetted starts in hold (the same rings I describe in Staying Current: Awareness vs the Trigger to Act).
• Don’t take brand-new releases immediately. Package managers can now ignore versions newer than a few days (pnpm’s minimum release age, uv’s exclude-newer). Most malicious versions are spotted and pulled within days.
• Turn off install scripts by default. Many attacks run the moment a package installs. npm ci --ignore-scripts, or pnpm, which blocks them unless you allow them.
• Prefer packages with provenance. npm provenance and PyPI trusted publishing show a package was built from the repository it claims to come from.
• Scan automatically. Dependency scanners flag new packages, unexpected install scripts and code that calls out to the network, at review time rather than after an incident.

2. Put guardrails on the agents

• No new dependency without a human approving it. Agent permission rules can require approval for package installs, even when everything else runs freely.
• Check that a suggested package is real. How old is it, who maintains it, does its download history make sense? That one habit defeats slopsquatting.
• Treat MCP servers, skills and extensions as dependencies. Pin versions, review them, and assume their descriptions could contain instructions aimed at the agent.
• Sandbox untrusted work. A container with no secrets and limited network access for anything you don’t fully trust.

3. Limit the blast radius

Assume something will eventually get through.

• Nothing worth stealing on disk. Keys in an agent, tokens injected at runtime, short-lived credentials (Protecting SSH: Keys Off Disk, in a Password Manager). If a secret has already leaked, see Removing Secrets from Git History.
• Restrict outbound network access from builds and services, so a backdoor can’t phone home.
• Keep domains separate. Clear boundaries between services mean a compromise in one part of the system stays in that part (Planes and Bounded Contexts).

4. Make it executable

A policy written in a document isn’t enforced. Make the build enforce it: CI fails when a dependency appears that hasn’t been approved, the same way Architecture Fitness Functions fail when an architectural rule is broken. And keep a software bill of materials for each service, so that when the next xz-style incident is announced, “are we affected?” takes minutes rather than days.

The honest limit

None of this catches a carefully hidden backdoor in a library you’ve chosen to trust. What it does is reduce how many things you trust, how quickly unvetted code reaches you, and how far one bad package can reach. In a world where convincing software can be generated on demand, those three are the controls you actually have.