Your AI agent has shell access. What is it installing in the background?

Until recently, AI assistance had a confirmation step. The assistant suggested an install command, you hit accept, the shell ran it.

That confirmation step is going away across the category. Several mainstream AI coding tools now ship an "agent" mode that can run npm install (and other shell commands) without prompting the user for each one — the model decides, the model executes.

This is great for shipping speed. It also moves a check that used to happen — you, glancing at the line before pressing enter — from the trust pipeline.

What the chain of trust now looks like

Before agent mode:

You → review → terminal → npm → registry → package

After agent mode:

AI agent → terminal → npm → registry → package

You're still upstream of the AI agent (you wrote the prompt), but the AI is now between you and the installation. And the AI doesn't:

Notice that the package was registered last week
Notice that the maintainer changed between versions
Notice that an install script downloads a binary
Recognize the difference between framer-motion and framr-motion
Read the actual code in node_modules after install

The model will install whatever its training data suggested or whatever Stack Overflow's first hit recommends — including names that don't exist (the agent will try to install them, fail, and quickly retry with a name that does exist, which might be a slopsquat).

The new failure mode

Three concrete scenarios that didn't exist when humans typed every npm install:

1. AI hallucinates a name and it resolves. Agent runs npm install <hallucinated-but-registered>. Package is malicious. You never typed it, you never saw it, the install logs scrolled past. The first you know is when your AWS credentials show up in a leaked dump.

2. AI installs the wrong package because it picked the most-similar real name. You asked for "a date picker." Three packages match. Two are popular and old; one is a slopsquat that ranked highly because it has aggressive SEO in its README. Without taste, agents grab the first plausible result.

3. AI installs deeply transitive dependencies you'd never have consented to. You meant to install a small utility. The util pulls in a build-tool wrapper that pulls in a polyfill that pulls in a postinstall script with curl-pipe-bash semantics. A human would notice the install log; an agent moves on to the next task.

Where the check has to go

If the agent is the one running the install command, the safety check has to live under the agent. Putting it in the editor's review UI is too late if there is no review UI. Putting it in code review is too late because the code is already on disk and the postinstall script has already fired.

The fix is to put the check at the registry layer. The agent runs npm install like normal. The local gate intercepts. The agent's command either succeeds (package is fine) or fails with a clear message (package failed scoring — here's why). The agent reacts the same way it reacts to any other command failure: try a different package, or stop and ask.

The AI doesn't need to know about supply-chain security. The gate doesn't need to know about the AI. They just need to compose properly.

Specifically what AI agents need

A few practical things that make the gate-under-agent pattern actually work:

The block needs to be a clean error. A hang or a confusing stack trace wastes agent attempts; a 403 with code=policy_blocked and the package name in the message gives the agent a clean signal to try something else.
Exit codes matter. The agent reads exit codes to know whether a step succeeded. The gate's refusal should propagate as a non-zero exit (it does — npm exits non-zero when the registry returns 403).
The sandbox needs to be invisible until something tries to escape it. If every npm install triggered a TUI prompt, agents would fail. The gate refuses bad packages before they download; the sandbox only fires the interactive prompt when a postinstall script attempts something outside its allowed paths.

How to set it up

veln onboarding
veln wrapper on

That's it. After that, every install command — whether you typed it, the agent typed it, or a postinstall script chained into it — routes through the same scoring layer. The agent keeps the speed it had. You get the check it doesn't perform.