Coding assistants checked provenance before installing software in just 9 of 1,920 controlled trials, or 0.5%, and never once ran a verification command. The September 2026 pre-registered study tested whether coding assistants would use software supply-chain signals such as SBOMs, signed releases, build provenance and declared official channels when deciding what to install. The research showed that they generally did not.
That finding points to a change in how software enters applications. AI coding agents can now identify dependencies, modify manifests, invoke package managers and resolve dependency conflicts as part of completing a development task. A developer can specify what an application needs to do without explicitly choosing every component that will be used to implement it. Part of the software-selection process has therefore moved inside an automated development workflow.
AI is changing how dependencies enter applications
Consider a developer asking an agent to connect a Python service to an external API. A common implementation could lead the agent to add requests. The package itself currently has four runtime dependencies: certifi,charset-normalizer,idna and urllib3. The developer asked for HTTP connectivity, but the resulting dependency graph can include five separately maintained packages, each with its own release history, publisher and security properties.
There is nothing inherently wrong with that dependency chain, because the packages can all be legitimate, the application can work correctly and the tests can pass. The organization may still prefer a different implementation because of its provenance, maintenance history, licensing requirements, dependency footprint or internal security policies. Those considerations are unlikely to be captured in a prompt such as “connect this service to an API.”
Software selection becomes harder to control when an agent handles much of the implementation. A developer may specify what the software needs to do, then rely on the agent and package manager to choose the dependencies needed to make it work. As a result, the final dependency graph may reflect what the model or package ecosystem favors without accounting for every requirement an organization uses to approve software.
Trust evidence does not automatically become a selection criterion
The industry has spent years building mechanisms that make software more verifiable. SBOMs provide a machine-readable inventory of components and dependencies. Signed releases and attestations provide evidence about artifacts and their publishers, while build provenance provides information about where software came from and how it was produced.
The 1,920-trial study shows why the existence of this evidence is not enough. The assistants rarely opened the available provenance information, and none executed a verification command. Publishing evidence and consuming evidence are separate problems.
An SBOM can tell a security team what ultimately entered an application without determining which package an agent should have selected. Provenance can provide evidence about the identity and production of a particular artifact without necessarily answering every question an organization has about that artifact.
The distinction is particularly relevant in Python. Under PEP 740, a PyPI attestation is bound to the distribution file’s cryptographic digest, which provides a strong identity relationship between the attestation and the artifact. It does not, by itself, establish that the artifact’s contents correspond to the source revision a developer intended to consume. Understanding that distinction between publisher provenance, artifact identity and source correspondence becomes important when dependencies are consumed automatically.
Existing controls mostly evaluate the result
SCA, SBOMs, vulnerability scanning and provenance remain important because organizations need to understand the software they build and deploy. They provide visibility into composition, vulnerabilities, origin and build history.
AI-assisted development introduces the question of, “which software should the development system be allowed to select?”
That question becomes more significant as agents gain the ability to execute package-manager commands, modify dependency files and resolve conflicts without waiting for a developer to approve each individual operation. At that point, dependency selection is part of an automated workflow rather than simply a recommendation presented to a human.
The answer cannot be to manually review every dependency introduced by an agent, because that would move the bottleneck from development to security and would become increasingly difficult as organizations adopt more autonomous development workflows. The more scalable approach is to constrain the software available to the agent before selection occurs.
Put verified software into the selection path
A practical implementation could give an AI coding agent access to an internal package index or software catalog containing pre-evaluated artifacts. Instead of resolving every dependency against the entire public ecosystem, the development environment could resolve against this controlled source. Each available artifact could carry the information needed for policy decisions, including its exact version and digest, publisher identity, provenance, vulnerability status, licensing information and dependency relationships.
The agent would still decide how to implement the developer’s request, but it would make that decision within a software supply that the organization has already evaluated. A policy could, for example, require a package to have an identified publisher, acceptable provenance and no unresolved critical vulnerabilities before making it available to development agents.
This does not replace downstream controls. SBOMs are still needed to understand what was ultimately built, vulnerability analysis is still needed as new issues emerge, and provenance remains important evidence about software origin and production. The difference is that these properties can also influence what the development system is allowed to consume, rather than being used only to evaluate the result afterward.
AI-assisted development is changing software supply-chain governance at the point where software enters an application. Organizations still need visibility into dependencies already present in a codebase, while automated development adds an earlier concern. Teams need to define which software these systems can select and provide verifiable evidence to guide those choices.
The goal is to give automated development systems access to a software supply whose provenance and policy status are known well enough that software selection itself becomes a governed part of development.
Biswajit De is the Co-Founder and Chief Technology Officer of CleanStart, where he leads the company’s technical vision and product strategy for securing modern software supply chains and cloud-native environments. With more than 17 years of experience in cybersecurity and platform engineering, Biswajit has led the development of innovative security platforms and foundational systems across product engineering, security operations, and large-scale enterprise infrastructure.
