Should coding agents need approval before adding dependencies?

I don’t think an agent should be able to silently merge a new dependency, even if the build passes and the package is widely used. “Widely used” reduces some uncertainty, but it does not rule out typosquatting, a malicious update, abandonment, or a build that can’t be reproduced later.

My practical compromise is to let the agent propose the change in an isolated pull request, generate and update the lockfile, and run CI checks for vulnerabilities, maintenance, provenance, and approved packages. For npm, the lockfile records the exact tree, and `npm ci` requires the manifest and lockfile to stay synchronized. Sensitive or production repositories should add a human approval gate; lower-risk projects can rely more on automated policy checks. Would you impose a hard gate everywhere, or trust a sufficiently strict automated review?

I’d block the merge, not the proposal. Making the agent stop before it can even prepare a lockfile and CI result throws away useful automation. The dangerous state is an unreviewed dependency entering the main branch, not a draft PR containing one.

A universal human gate sounds safe until people start rubber-stamping it. If the checks explain what changed and reject anything outside policy, I’d reserve manual approval for production, sensitive data, or unusual packages.

The distinction matters: the brief supports controlled addition and review, but it does not establish a universal rule requiring a human for every AI-introduced package. I’d treat that as a repository risk decision, documented rather than assumed.

For a tiny side project, I want the agent to add the library and keep moving. I can inspect the diff afterward. For anything customer-facing, the same behavior should open a PR and wait. One workflow for both is needless friction.

Passing tests is almost irrelevant to the supply-chain question. Tests tell me the code behaves against the cases we wrote; they don’t tell me whether the package name was mistyped or whether its transitive tree is acceptable.

The approval gate needs an owner and a response time, or it becomes an unattended queue. An isolated dependency PR with a required check is workable. A vague instruction to “review security” is process theater.

I’m less convinced that “provenance” should be treated as a magic green light. Even a legitimate, well-maintained package expands the attack surface. The policy should make the residual risk visible, not pretend to eliminate it.

In an enterprise repository, the hard gate is easier to defend because dependency approval can map to an existing ownership process. An allowlist also makes the exception path explicit instead of asking reviewers to recognize every safe package from memory.

Lockfiles solve reproducibility of the selected tree, not the decision to select that tree. I’d have the agent update the lockfile in its branch, then let CI compare direct and transitive additions before anyone merges.

If the agent can add packages without asking, it is not an assistant. It is an uninvited maintainer. Let it do the paperwork quickly; make a human own the addition.

I’d also separate network access from repository editing. An agent that can suggest a dependency but cannot install arbitrary code in the development environment has a much smaller blast radius while the review happens.

The cost is not just seconds per PR; it’s losing momentum on small fixes. A policy gate that only escalates new or unusual packages gets most of the safety benefit without making every routine change wait for a specialist.

The review interface matters. Show the old and new manifests, the lockfile diff, package age, usage, and why the agent chose it. People approve better when the decision is legible instead of buried in generated changes.

I’d be careful with “widely used” as a proxy for safety. It is evidence of adoption, not a guarantee about current maintenance or future updates. That’s enough reason to require checks, but not enough to justify pretending every package is equally risky.