An arXiv preprint published on 17 July 2026 shows that editing a single README, requirements file, or Makefile is enough to redirect an AI coding agent toward untrusted package registries and known-vulnerable dependencies [S1]. The same model that catches an attack in one coding harness installs the malicious package through another [S1]. The gap between those two outcomes is where the danger lives.

How the attack works

AI coding agents set up projects the way a junior developer does on their first day: they read the documentation, follow the install instructions, and run the commands it lists [S1]. The problem is that they do this without checking whether the package names are real, whether the sources are trusted, or whether the versions have known vulnerabilities [S1].

An attacker who can edit a project's README, requirements file, or Makefile can redirect the agent in three ways: point it at an untrusted package registry, specify a known-vulnerable version of a real package, or use a wrong-but-plausible name that the agent installs without question [S1]. The documentation itself becomes a delivery mechanism for code execution [S1].

The study, by Aadesh Bagmar and Pushkar Saraf, tests frontier models across twelve scenarios in five attack classes, all grounded in documented real-world incidents [S1][P2]. The authors position it as an initial structured assessment of supply-chain attacks that exploit routine setup documentation to compromise production coding-agent harnesses at package-install time [S1].

Where the agents fail

The results split along two axes: what kind of attack is used, and which harness-model combination is running it.

Agents catch blatant typosquats reliably [S1]. If someone registers a package called "requ3sts" instead of "requests", the agent usually notices. But plausible separator-confusion names, like "azurecore" instead of "azure-core", slip through [S1]. How often they slip through depends on the specific harness and model pairing [S1].

The biggest blind spot is source-based attacks. When an attacker redirects the agent to an untrusted package registry rather than swapping the package name, agents miss it almost everywhere [S1]. This recurs across npm and Cargo, where nearly every model tested installs the untrusted dependency without flagging it [S1]. Name detection, by contrast, carries over less consistently across ecosystems [S1].

Security-oriented prompts help, but only partially. They recover part of the gap, but only for the specific dimension the prompt names [S1]. Tell an agent to watch for suspicious package names and it will, but it will not start checking whether the registry URL is legitimate.

What it means

The core finding is that install-time security depends on the harness-model combination, not the model alone [S1]. A developer who switches from one coding-agent harness to another, keeping the same underlying model, may gain or lose protection against supply-chain attacks without knowing it.

This matters because coding agents are increasingly given terminal access, filesystem control, and outbound network permissions to set up and run projects. A related arXiv preprint, "You Told Me to Do It: Measuring Instructional Text-induced Private Data Leakage in LLM Agents", shows that privileged agents handling external documentation can expose sensitive data through the same trust pathway [P5]. The through-line is consistent: agents trust documentation the way humans trust a colleague's instructions, and that trust is exploitable.

The fix the authors propose is a deterministic pre-install check that verifies package names, sources, and versions before any code runs [S1]. This is not a model-level fix. It is a guardrail that sits between the agent's decision to install something and the actual installation, checking the basics that the model itself cannot reliably check.

What it means for business

For a two-person startup using an AI coding agent to scaffold a new project, the risk is concrete. If the agent clones a repository and follows its setup instructions, a poisoned README or requirements file can lead it to install a malicious package with the same permissions the agent has, which often includes filesystem write access and network access [S1].

A suburban web agency that uses coding agents to quickly stand up client projects faces the same exposure. The agent reads the README, runs the install commands, and the project is ready. If an attacker has edited the setup instructions, the agent may install a package from an untrusted registry without flagging it [S1].

The practical step is to ensure that whatever coding-agent harness the team uses has a deterministic pre-install verification layer, rather than relying on a security-focused system prompt alone [S1]. Teams should treat external repository setup instructions the way they treat any untrusted input: with verification, not trust.

What we don't know yet

The preprint has not been peer-reviewed, and the authors' claim of a "first systematic evaluation" is self-assessed [S1]. The specific models, harnesses, and ecosystems tested are not fully itemised in the abstract, so it is unclear which production coding agents were tested and which were not.

The study is grounded in documented incidents, but the paper evaluates research scenarios rather than active in-the-wild exploitation [S1]. There is no evidence in the pack that these attacks are currently being used against real coding agents in production.

The paper is cross-listed under both cs.CR (cryptography and security) and q-fin.GN (general finance), which may confuse readers about its scope. It is a computer-security preprint, not a finance paper [S1].

The next thing to watch is whether coding-agent harness vendors add deterministic pre-install checks in response to this work, and whether independent researchers replicate the findings across a wider set of models and ecosystems.

Sources

More from Not A Tech Guy

Generated from an audited evidence pack with primary-source research. Social-media items are discussion signals, not verified facts. Nothing here is financial, legal or medical advice.