Should AI coding agents need a dependency gate?

I’m increasingly uneasy with coding agents being allowed to add or upgrade dependencies as if that were an ordinary implementation detail. I’d like to see a dependency gate before merge: the agent must show provenance, license, the transitive dependency diff, maintenance signals, and known security issues, then obtain explicit human approval.

Most of this is already technically approachable. Dependency graphs and review tooling can expose versions, licenses, vulnerability findings, and transitive changes. Provenance can make a package’s source and build process auditable, though it is not proof that the code is safe. Maintenance scores are useful prompts for investigation, not verdicts.

That review could slow prototyping and burden small teams. Still, generated code may make supply-chain decisions easier to overlook because the dependency arrives as part of an apparently complete solution. Should the gate be mandatory, configurable by repository risk, or left to developer judgment?

Configurable by repository risk, but with a hard floor. For a throwaway prototype, a warning may be enough. For production or anything handling sensitive data, silently adding a package should be treated like changing an external trust boundary. The agent can prepare the change; it should not smuggle it through.

I’m sympathetic, but “show everything” can become a ritual nobody reads. Small teams need a fast path for familiar, well-established packages and a slower path for unusual ones. The important part is that the agent cannot hide the manifest and lockfile diff behind a green test run.

The distinction between evidence and assurance matters here. Provenance can connect a package to a source commit and build workflow, but it does not establish that the package is benign. Likewise, low maintenance activity is a reason to investigate, not a risk score that should automatically reject it.

I’m not convinced explicit approval is the right control in every repository. Humans routinely approve dependency updates mechanically, so the gate may create compliance theater. A policy that blocks unexplained or high-impact changes, while allowing documented exceptions, seems more defensible than requiring a ceremonial click every time.

For larger organizations, the useful output is probably a consistent review record: what changed, which policy applied, and who accepted the residual risk. Repository-level configuration could map that burden to the consequences of failure instead of imposing enterprise process on every experiment.

The transitive diff is the part I’d insist on. “Added one small helper” can mean adding a whole subtree. I’d also make the agent explain why the dependency is needed and whether the task can be completed with the existing stack. That catches unnecessary additions before security tooling even enters the discussion.