Do AI Coding Assistants Check Before They Install? A Pre-Registered Demand-Side Audit of Trust Signals in the Research Software Supply Chain
Pre-registered audit finds AI coding assistants verified provenance signals in only 9 of 1,920 trials before installing research software packages.
The study tested whether AI coding assistants check machine-readable trust signals such as SBOMs, signed releases, and provenance attestations before installing six open-source research software projects spanning HPC and quantum computing. Three models under two operating modes produced 1,920 registered trials scored from container logs. Provenance signals were opened in only 9 of 1,920 trials (0.5%) and zero of 384 control trials, with no trial running a verification command. The authors conclude publishing signals is insufficient and verification must be built into the program running the assistant.
- Verification occurred in only 9 of 1,920 trials (0.5%), none in controls
- Signal presence had no measurable effect on assistant install behavior
- A $0.10-per-trial model verified most; a $1.00 frontier model verified nothing
- Recommendation: enforce verification inside the agent runtime, not by convention
Full article287 words · extracted from arxiv.org · click to collapse
AI coding assistants now select, install, and configure software, and attackers have exploited that position through invented package names, compromised maintainer accounts, and manipulated repository text. In response, the supply-chain community publishes machine-checkable trust signals: software bills of materials, signed releases, build provenance attestations, and declared official channels. Whether coding assistants read or act on those signals has not been measured for any of these classes on research software. We pre-registered and ran a controlled study on six open-source research software projects (three HPC, three quantum computing) drawn from an 87-project corpus, with protocol, seed, panel, and analysis plan deposited with a DOI before any trial. W created nine modified copies for each project: no signal, one per signal class, two with a signature or attestation from the wrong issuer, one with all four signals, and one reproducing documented conflicts in the project's own metadata. Three models under two ways of operating an assistant, with and without an approval step, gave 1,920 registered trials, plus a supplement on three frontier models. We scored behavior from container logs rather than from what the assistant said, and recorded the cost of every trial. Verification was rare under every condition: in 9 of 1,920 registered trials (0.5%), the assistant opened any provenance signal before installing in 0 of 384 control trials, and no trial ran a verification command, so signal presence had no measurable effect. We drew three conclusions: publishing signals is necessary but not sufficient; price did not buy verification (the model that verified most often costs $0.10 per trial; the most capable, at $1.00, verified nothing); verification must be built into the program that runs the assistant. We release the per-trial cost ledger, the protocol, and every log.
Text extracted automatically; images, tables and formatting may be missing. Original: https://arxiv.org/abs/2609.07754