Supply Chain

An agent that can add a dependency can add arbitrary code with arbitrary privileges to a build. This is the highest-leverage attack surface in agent-assisted development, and it is governed separately from ordinary file edits.

Why dependencies are privileged#

A patch to source code is reviewable — a human reads the diff and sees what it does. A single-line addition to a manifest is also a small diff, but it pulls in a tree of code nobody reads, often executes install-time scripts, and inherits the full permissions of the build environment. The review effort is wildly disproportionate to the apparent size of the change, and attackers know it.

Substitution and typosquatting#

A model asked for a package by name will, when the name does not resolve, sometimes reach for something that looks close enough. That behaviour is precisely what package-name squatting exploits. The runtime therefore resolves every proposed dependency against the existing manifest and the indexed repository before installation, and a name that no existing code references is treated as a new dependency requiring approval, regardless of how plausible it looks.

• Hallucinated packages — a name the model produced but that does not exist is a failed resolution, never an invitation to install the nearest match.
• Name proximity — a proposed name within a small edit distance of an existing dependency is flagged rather than installed.
• Age and provenance — recently-published packages with no history in the ecosystem are surfaced explicitly in the approval prompt.
• Lockfile integrity — the resolved tree is pinned by hash; an install producing a different tree than the plan described fails closed.

Related material: Sandboxing covers the execution boundary itself, and CI Integration covers why an agent may never modify the pipeline that enforces these checks.