Software supply chain security was hard enough. Then AI joined the build pipeline.
For five years, “software supply chain security” meant one question: what’s in your code? Which open-source packages, which versions, which transitive dependencies three layers deep that nobody chose on purpose?
SolarWinds, Log4Shell, and XZ Utils all taught the same lesson: the risk lives less in the code a team writes and more in everything that produces it. Shai-Hulud, the self-propagating malicious package campaign that spread through developer toolchains this year, taught the next one: knowing what’s in your code is still necessary, but it’s no longer sufficient.
In the roughly 20 months since the Model Context Protocol launched, AI tools, models, and the infrastructure around them have become load-bearing parts of how software gets built, deployed, and run. Code is written by agents. Packages are pulled in by autonomous tools that decide they are needed. Prompts have become a real input to the build, which means they’re a real way to compromise it. None of this was in scope when most security programs were designed.
Where the risk actually moved
It’s tempting to treat AI-generated code as just more code, run it through the same scanners, and call it covered. That misreads where the risk moved.
The provenance question that has always defined supply chain security – where did this come from and can I trust it – now applies to the model, the agent, and the tooling, not only the artifact. An AI coding assistant suggests a dependency and a developer accepts it without the package ever crossing a human’s threat model. An autonomous agent reaches for a tool over MCP to complete a task, and that tool reaches for another. A prompt, crafted by an attacker and planted somewhere the model will read it, steers what gets written or what gets pulled in.
Validating AI-generated code before it’s committed is table stakes. The harder problem is governing the agents doing the writing and the tools they call.
What a program looks like when AI is in scope
The teams we work with aren’t short on findings. They’re drowning in them. Adding “scan the AI output too” to an already overloaded queue makes the alert pile taller, not the program stronger. Two things change when AI is genuinely in scope.
First, lineage has to extend to everything entering the pipeline, including the models and agents.One approach is extending lineage to the pipeline itself – tracing activity, provenance, and configuration changes from first commit to runtime, and applying the same rigor to models and agents as to any other dependency.
Second, prioritization has to be based on real exploitability, not volume. Correlating findings with runtime context with what’s actually reachable is the difference between a vulnerability list and a workable chain of exploit. That difference matters more, not less, once an agent can generate a thousand lines of plausible code before lunch.
This is the gap that Gartner formalized in June when it published the inaugural Magic Quadrant for Software Supply Chain Security – the market’s acknowledgment that a problem teams have been defending without a budget line is now something worth evaluating systematically.
On July 22, OX researchers are hosting a webinar – How AI Is Reshaping Supply Chain Security As We Know It – to walk through new research alongside security leaders doing this work from the inside. We’ll cover how AI integration changed the attack surface, findings from the first systematic look at MCP servers in the wild, and what a supply chain security program actually looks like when AI is in scope rather than bolted on after.
Register here. Bring hard questions.
