Coding Agents Can Install the Wrong Package Faster Than Your Team Can Notice
Add dependency allowlists, provenance checks, sandboxing, lockfile review, and network controls to AI-assisted software development.
A plausible import can hide a supply-chain decision
When an AI coding agent encounters a missing library, it may suggest a package that appears to solve the problem. The package could be abandoned, typo-squatted, compromised, overprivileged, or simply unnecessary. A developer may approve the change because the import looks reasonable and the build passes.
Agents with terminal access can turn dependency selection into an action rather than a recommendation. They may edit a manifest, run an install script, update a lockfile, or access the network. This makes package hygiene part of the agent's permission design.
Before enabling automatic installs, define which registries, package managers, scopes, and lifecycle scripts are allowed. A sandbox limits damage, but it does not tell you whether the package belongs in the product.
Make dependency changes visible
Require the agent to explain why a dependency is needed and what existing capability it replaces. Prefer established packages already in the repository. Verify the exact name, registry, maintainer, release history, license, and supported runtime. Do not trust a package description copied into a model response; inspect the registry and project source.
Keep lockfiles reviewed. Check whether the change adds unexpected transitive dependencies, changes integrity hashes broadly, or upgrades unrelated packages. Use reproducible installs and pin versions according to project policy. A huge lockfile diff deserves an explanation, not a reflexive approval.
Protect install scripts. Run package installation in an isolated environment with no production secrets and limited network access. Where feasible, disable or review lifecycle scripts. Prevent a package from reading developer credentials or CI tokens during an agent run.
Control network and registry access
Use approved registries or proxies and log package retrieval metadata. Block arbitrary outbound connections from code execution unless the task requires them. If the agent needs documentation access, provide a constrained route rather than unrestricted access to internal services.
Separate development credentials from deployment credentials. Agent environments should receive only what a task needs, ideally no secrets at all. Never mount a production key to make a test convenient. Use short-lived, read-only tokens where access is unavoidable.
Monitor for package additions, install-script changes, and altered CI permissions. Require human approval for new direct dependencies and changes to registry configuration. Automatic checks can flag known vulnerabilities and suspicious metadata, but they do not replace maintainers' judgment.
Test the agent workflow itself
Create tasks that mention a nonexistent package, a typo-similar package, and a feature available through the standard library. Verify that the agent asks for confirmation rather than installing blindly. Test a compromised or unavailable registry response in a controlled environment and ensure the agent does not switch to an untrusted source.
After a coding run, inspect package manifests, lockfiles, scripts, workflows, and generated artifacts. Run dependency scanning and license checks. Compare the final diff with the initial tree and check whether the agent changed security settings to get tests passing.
Keep provenance for the model, prompt, sandbox image, package registry, and resolved dependencies. If an incident occurs, the team should be able to identify what the agent downloaded and which execution environment received it.
Make the safe path the easy path
Provide the agent with a local map of approved packages, examples from the codebase, and commands for tests. A clear internal developer platform reduces the chance that it searches the public registry for every missing helper. Maintain the map and remove outdated recommendations.
Supply-chain controls should not depend on a model remembering a warning. Enforce registry rules, isolate installs, minimize credentials, and review lockfile changes. Agents can speed up implementation, but the organization remains responsible for every dependency that reaches a shipped product.
When a package is approved, record the reason, owner, and expected update path. Set a reminder to review abandoned or unmaintained dependencies, and define who handles a security advisory. This makes the original decision visible months later, when another agent or developer sees the package and assumes it is a standard part of the stack.
Check whether the license is compatible with how the product is distributed, and route uncertain cases to the appropriate reviewer before merge. A vulnerability scanner does not answer the license question, just as a license file does not prove a package is safe to execute.