Your Coding Agents Are Making Supply-Chain Decisions

“You can't trust code that you did not totally create yourself.”
— Ken Thompson, “Reflections on Trusting Trust” (1984)

Put a human approval on every new direct dependency, keep agents away from credentials that matter, and make every build install exactly what was reviewed. Those three controls cost an afternoon at seed and a few weeks at Series B, and they cover most of the new risk that coding agents bring to your software supply chain. Everything else is a matter of stage.

Picture an engineer asking a coding agent to add CSV export to a reporting page. The agent searches, picks a library, runs the install, finds the API doesn't quite fit, installs a second library, and gets the tests passing. The pull request is tidy. Buried in it is a lockfile diff of several hundred lines covering dozens of new transitive packages, and somewhere during the session a post-install script ran on a laptop that holds a cloud credential and a GitHub token.

Nobody decided to take on those dependencies. They arrived as a side effect of a feature request.

What is new, and what isn't

The common reaction from experienced engineers is that none of this is new, and they are mostly right. Typosquatted packages, compromised maintainer accounts and malicious install scripts have been a problem for as long as public registries have existed. Teams that already review dependencies carefully have less to change than the headlines suggest.

What has changed is who makes the call and how often. A person adding a dependency at least typed its name and probably glanced at its page. An agent can add five in a session, choose between similarly named packages on the strength of its training data, and sometimes suggest packages that don't exist at all. A study of package hallucinations across sixteen code-generating models found that at least 5.2% of the packages suggested by commercial models, and 21.7% from open-source models, did not exist, across more than 200,000 unique invented names. Every one of those names is a package an attacker can register and wait for an agent to install.

The numbers deserve some caution. They come from generated code samples rather than live agent sessions, and an agent that runs the install and reads the error will often correct itself. But the direction is clear, and the volume of dependency decisions has gone up regardless. Each added package is a small buy decision: you take on someone else's code, release schedule and security record, usually for free and usually forever.

Agents are already in your dependency tree, so debating whether to allow them is moot. The question for a technology leader is where a human still has to say yes, and how cheaply you can make that happen.

Where the decisions are being made

Four kinds of decision now happen inside agent sessions, often without anyone noticing.

The first is adding a direct dependency: choosing a package to solve a problem the standard library or an existing dependency might already handle. That choice also brings a license, and a copyleft package pulled into proprietary code is a legal question before it is a security one, as the guide to software licenses explains. The second is version choice: loosening a pin to resolve a conflict, or pulling the latest release of something that was deliberately held back. The third is execution: installing packages runs their lifecycle scripts by default in several ecosystems, and agents also run whatever build, codegen or setup commands they decide are needed. The fourth is access: an agent running in a developer's shell inherits that developer's environment, which usually means tokens, cloud credentials and SSH keys.

The first two show up in a diff, if anyone looks. The last two often leave no trace in the pull request at all, which is why they matter more. Vulnerable and outdated components have sat in the OWASP Top 10 for years; agents change how quickly they arrive, not what they are.

Guardrails that fit the stage

The right controls depend on how big the team is and what you are protecting. Copying an enterprise supply-chain program into a five-person startup will slow it down without making it much safer, the same right-sizing argument that applies to platform work.

Seed: an afternoon of setup

Commit lockfiles and make CI install from them exactly (npm ci, pip install --require-hashes or your ecosystem's equivalent), so what was reviewed is what gets built. Turn on your platform's dependency alerts. Add a line to the agent instructions file in each repo: ask before adding a new dependency, and explain why the existing ones won't do. Agents follow those instructions most of the time, which is far better than never.

Most important at this stage, keep production credentials off the machines where agents run. Long-lived secrets in shell profiles were already a bad idea, as covered in secrets management done right. Agents make them a worse one, because the thing reading your environment now takes instructions from web pages and package READMEs as well as from you. The cost of this step is mostly inconvenience. The cost of skipping it is a leaked cloud key at a company with no security team to notice.

Series A to B: make the dependency decision visible

Once there are several teams and agents are in daily use, treat a new dependency as its own review item. A code-owners rule on manifests and lockfiles means someone with context approves every new direct dependency. A CI check can go further and flag new direct dependencies, new packages with install scripts, and very new or little-used packages, then post a short summary on the pull request so the reviewer reads a few lines instead of a long lockfile diff. This matters more as agents raise the volume of pull requests, which turns reviewer attention into the scarce resource, a point leading teams where agents write half the code makes at length.

Disable dependency lifecycle scripts by default and allowlist the few packages that genuinely need them; npm, for example, supports this through its ignore-scripts setting, and several other package managers now offer the same. Run agents in a sandbox: a dev container or remote workspace with short-lived, narrowly scoped tokens and, ideally, restricted network egress. Add a vulnerability scanner to CI with a clear rule about what blocks a merge, typically a known critical or high issue that already has a fix, so the scanner doesn't become noise everyone ignores.

The trade-off here is real. Each of these controls adds friction, and engineers will feel it before they see the benefit. Picture a Series B company where an agent-added package with a post-install script exfiltrates a developer's token, and the token reaches a production database. The incident costs a week of engineering time, a customer notification and a difficult renewal conversation with the largest account. The controls above would have cost a few days of setup and a few minutes per pull request. Present it to the executive team in those terms, and it stops being an engineering preference.

Later stage: policy and provenance

At scale, and especially once customers ask for it, move to an internal registry or proxy that serves only approved packages, produce an SBOM for what you ship, and prefer packages with published build provenance where your ecosystem supports it. The SLSA framework gives a shared vocabulary for those provenance levels, which helps when a customer's security team asks what you can prove about your builds.

Give agents their own identities with their own permissions and audit logs, so you can answer "what did the agents install last month, and where?" without reconstructing it from shell histories. Pair this with the build-once discipline from code promotion: the artifact you scanned should be the artifact you deploy. At this stage supply-chain exposure also belongs on the board's risk register, with an owner and a trend, as part of reporting engineering to the board in terms directors can act on.

What not to do

Banning agents doesn't work. Engineers will use them anyway, just without the guardrails. Routing every pull request through a security reviewer doesn't work either, because the queue grows until people find ways around it. And a scanner that fails builds on every moderate finding with no fix available trains the team to ignore it.

Most dependencies an agent adds are fine. The aim is a cheap, visible point where a person who understands the codebase agrees to the new code, and an environment where the occasional bad package can't reach anything that matters.

What good and bad look like

Good looks like this: a reviewer sees "this PR adds two direct dependencies, one with an install script" at the top of the pull request and asks why. The agent ran in a container whose token expired an hour later. Lockfiles drive every build, and the scanner blocks only what someone has agreed should block.

Bad looks like agents running in a senior engineer's shell with an admin token in the environment, lockfile diffs approved unread because they are too long to read, and a dependency count that has doubled in a year without anyone choosing to double it. The same thinking applies to the tools agents call, which hardening an MCP server covers from the other side.

Before the next engineering leadership meeting, run your package manager's "why is this installed?" command on three dependencies added in the last month. Then ask the room two questions: does anyone remember choosing them, and which credentials could their install scripts have read?