When someone hands an unfamiliar repository to a Coding Agent, the first thing many people say is: “Just get the project running.” In the past, a human setting up the environment would at least read through the documentation and copy commands one by one. The Agent, however, reads the instructions and directly generates and executes installation commands. This makes it easy for people to treat setup as merely preparatory work.
The preprint paper Setup Complete, Now You Are Compromised
points out the time gap here: downloading dependencies itself can
execute code. While the developer is still waiting for the environment
to be ready, the installation script inside a software package may
already be running. By the time the final diff appears, the first code
execution may have long since concluded.
The authors constructed twelve scenarios and five categories of attacks along this path, and tested nine Coding Agent configurations composed of different models and clients. All results come from the authors’ experiments and currently lack independent reproduction; these constructed scenarios also do not prove that such attacks are widespread in practice. Experimental details and limitations can be found in the HTML version of the paper.
To start the project, the Agent first reads the README
and dependency configuration—for example, pyproject.toml,
requirements.txt—and sometimes consults the
Makefile or CI configuration. It then invokes pip, npm, or
Cargo to download software packages from external sources and install
them into the development environment. The rest of this article refers
to such dependency management tools collectively as package manager.
Fetching a software package is not merely copying files. Python
packages can run setup.py during build or installation, and
execute __init__.py on first import; npm packages can set
postinstall; Cargo runs build.rs when building
dependencies. These entry points originally serve compilation and
environment configuration, but they also allow software packages to
execute code during installation, build, or first import.
If the project instructions direct the Agent toward an attacker-controlled software package, the package manager may execute the code within it. At this point, the Agent has not yet begun modifying business files, and the developer has no final diff to inspect. The project not yet being started does not mean third-party code has not yet run.
Malicious code does not need to appear in the repository. The project configuration or a Pull Request can contain only a seemingly ordinary dependency change, while the actual code to be executed resides in an external software package, waiting for the package manager to download it.
In April 2026, in “Configuration Files of AI Coding Tools Are Now Attack Vectors”, I discussed a different risk: attackers placing malicious text in a repository, which the Agent mistakenly interprets as instructions. The installation requirements in this paper, however, do not need to masquerade as malicious commands. Installing dependencies is, to begin with, a normal task authorized by the developer.
The authors conducted a control experiment. They had the program suggest, in an error message, installing an attacker-specified software package—all nine tested configurations rejected the request. In this set of experiments, the client treated the program output as untrusted content and did not blindly comply.
When the same installation suggestion is written into the project instructions, its role changes. The Agent needs to refer to these documents to configure the environment; if it rejects all installation requirements in the documentation outright, “getting the project running” becomes impossible.
An attacker can therefore modify only the documentation or dependency configuration, redirecting the installation command to a different software package or download source. The reviewer sees a dependency change, but does not automatically see what that external software package does during installation.
An installation command decides at least three things: which package to install, where to download it from, and which version to use. The paper found that the Agent’s judgment differs across these three choices.
Obvious typos are the easiest to trigger vigilance. When the authors
misspelled transformers as tranformers, nearly
all tested configurations detected the anomaly. With a separator
difference such as azurecore versus the real package
azure-core, the results depended on the specific model and
client combination. The same model with a different client could yield
different experimental results.
Even when the package name is correct, the download source can still
change. The package manager typically retrieves code from the default
registry, i.e., the software package index. When a project uses private
packages, it may add another index via --extra-index-url; a
normal-looking package name can thus be resolved and downloaded from an
attacker-controlled source. The paper reports that clients intercepted
such scenarios less frequently overall than scenarios with obviously
misspelled package names.
Version is another path. The authors kept the package name and source legitimate, and only requested installation of an outdated version already listed in the CVE public vulnerability database. All nine configurations completed the installation, and some only issued warnings afterward. There is no evidence here that attacker code had already run; the result is that the development environment enters a known vulnerable state, creating conditions for subsequent exploitation.
The final diff can only answer which repository files the Agent changed. It does not automatically list the code that the package manager previously downloaded and executed. A model warning about a suspicious package name or vulnerable version after environment setup has finished cannot undo an installation script that has already run.
An external software package can even run its script without modifying any business source code at all. In this case, the diff has not missed any repository changes—it was simply never responsible for recording the execution history of dependency installation.
HTTPS, signatures, and hashes can help confirm that downloaded content has not been replaced in transit; lockfile records already resolved versions so that subsequent installations reproduce the same result. They protect transmission and reproducibility, but do not assess whether the initially chosen software package, source, and version are correct.
If the project configuration pointed to an attacker-controlled package from the start, hashes can accurately verify that package, and lockfile can continue to reproduce it. The security check must happen before the package manager begins installation.
When the Agent is about to run an installation command, the client can pause first and display the package name, registry, and version from the command separately. What the developer sees at this point is the actual target of this installation, not just an entire terminal command that is difficult to verify.
The client can then verify this information against project rules: whether the name matches a software package the team intends to use, whether the registry is authorized, and whether the version has known vulnerabilities. If any item cannot be confirmed, the installation remains paused until the developer understands the reason and decides whether to proceed.
Real-world projects use internal company registries, Git dependencies, or local scripts, so this set of rules cannot be reduced to a public software package checklist. Teams need to configure exceptions based on the sources and dependency forms actually used by each project. The paper also did not measure the false-positive cost of such rules in real projects.
Dependencies that pass inspection should still be installed in a sandboxed environment. The installation process does not have access to long-lived credentials, and the network only opens to destinations needed for the task. Pre-installation inspection reduces the chance of selecting the wrong software package, while a sandboxed environment limits the impact after code runs—the two address different problems.
From now on, when telling a Coding Agent to “get the project running,” ordinary users need to understand this as authorizing the execution of third-party code. For teams building Agents or harnesses, parsing the package name, source, and version before installation, pausing and requesting approval when anomalies are detected, and completing installation in a sandboxed environment should all become default capabilities of the client. This security boundary belongs to the execution layer and cannot rely solely on the model’s ad-hoc judgment.