The Package You Didn't Choose
When the agent installs the packages, you're no longer the one who knows what's on your machine.
Recent news has been full of npm supply-chain attacks, like the self-replicating worm researchers named Shai-Hulud, which compromised hundreds of packages, stole credentials and tokens off developer machines, and republished itself into other packages automatically. I read the coverage the way you read about a storm in another state. Then I tried to check whether I was exposed, and ran into a problem that was entirely my own doing: I didn’t actually know what was installed on my machine.
Because I’ve stopped being the one who installs things.
The cost of not being the one who types
My whole workflow is now asynchronous: I prompt an agent, walk away to homeschool my three-year-old, come back minutes to hours later, prompt again. It’s the only thing that fits a parent developer’s fragmented day.
But there’s a bill attached, and this post is it. When the agent is the one writing the code, the agent is also the one reaching for dependencies. It needs a functionality, it pulls a package. It needs another, it pulls that one too. Multiply across weeks of lighlty supervised work and the result is a machine whose dependency tree I had never personally reviewed — assembled, decision by decision, by something that wasn’t me, while I was making breakfast.
So when Shai-Hulud hit, I couldn’t answer the only question that mattered: am I running any of these packages? I had outsourced the choosing, and the choosing turned out to be exactly the thing security depends on.
The audit, and the decision that came out of it
The fix, fittingly, was also agentic — but with more supervision. I had my agents go project by project: inventory every dependency, cross-check against the lists of known-compromised packages, flag anything unpinned, and pin what remained to specific known-good versions. It was a few hours of work I would rather have spent elsewhere, and it came out clean, which I credit more to luck and stack choices than to virtue.
The lasting change was a decision the audit forced me to: where I can, I’ve moved off npm entirely. Not because npm is uniquely evil — it’s the biggest target because it’s the biggest registry — but because the agentic-plus-npm combination concentrates the exact risk I’m least able to absorb. The JavaScript ecosystem’s deep, transitive dependency trees mean one poisoned package cascades into thousands of projects, and an agent with permission to install will pull the whole tree without a second thought. Reducing my surface area there was the highest-leverage thing I could do, so I did it.
Why agents make supply-chain attacks worse, specifically
This is the part worth internalizing even if you never touch JavaScript, because it generalizes to every package ecosystem and every agent.
The old supply-chain threat assumed a human at the keyboard, typing install and occasionally pausing to think wait, is that the right package name? That pause was a security control. We just never called it one.
Agents removed the pause. Two new failure modes follow directly:
Slopsquatting. LLMs hallucinate package names — they confidently reference a library that sounds right but doesn’t exist. Attackers noticed, and now register the hallucinated names as real, malicious packages, waiting for the next model to suggest them and the next agent to install them. Researchers estimate around a fifth of AI-generated code samples reference packages that don’t exist; every one of those is a slot an attacker can pre-fill. A human might squint at an unfamiliar name. An agent on auto-approve types it and moves on.
Unsupervised installation at machine speed. The whole point of an agent is that it acts without you. Point it at a task with broad permissions and it will fetch, install, and execute dependencies faster than you could review a single one — and increasingly, the attacks themselves target the agent’s own extensions and skills, which run with the agent’s full permissions. The convenience and the vulnerability are the same property. You cannot keep one and refuse the other.
The uncomfortable synthesis: the more useful the agent, the less you know about what it did. And what you don’t know, you can’t secure.
The wall, and why it’s the real answer
You cannot vet every package an agent pulls — not while sleep-deprived, not in the one-minute windows between parenting and existing. Vetting doesn’t scale to agent speed. So the strategy can’t be inspect everything; it has to be contain everything, so that the stuff you didn’t inspect can’t hurt what matters.
I run agents in disposable containers, never on my bare machine. Whatever an agent pulls, it pulls into a box that holds the project and nothing else — no SSH keys, no other clients’ code, no home directory full of credentials for a worm to harvest. Compromise the box and you’ve compromised a box I can delete in seconds.
The riskiest work lives on separate hardware. My autonomous agents run on a small dedicated machine — a NUC — physically apart from the computer that holds anything I’d grieve. Some basic network egress controls sit around it, so a compromised dependency can’t quietly phone home with whatever it found. The place where unreviewed automation runs should not be the place where your life’s details are stored.
Plan mode is the cheap half of the defense. Before any of the container stuff, I read the agent’s proposed approach and approve it. That single synchronous minute is where I’d catch let’s add this unfamiliar dependency before it executes. It’s not sufficient — plenty happens after approval — but it’s the highest-value minute in the workflow, and skipping it is how people end up not knowing what’s on their machine. I would know.
The sustainable version of autonomous work
I’m not going back to typing every install myself; the fragmented-time math doesn’t allow it, and that’s the whole reason this works for a parent at all. So instead I assume the agent will, sooner or later, reach for something it shouldn’t — and I make sure that when it does, it’s reaching inside a box I can throw away, on a machine that isn’t the one my life runs on. Build fearlessly, just in a box.
Building alongside your kids, not just around them? 12 Weeks of Tech Projects for Toddlers covers the safe-setup principles in a version pitched at age 2+ — same instinct, smaller stakes. At buildwithyourkid.com.