Supply Chain Risks When AI Agents Modify Dependencies

AI coding agents no longer just suggest code for you to approve. They select dependencies, install packages, and run build commands on their own, so they act as participants in the software supply chain rather than tools that sit beside it. The change that made this possible is structural: the Model Context Protocol, an open standard for connecting AI agents to external tools and data sources, now sits inside build pipelines at organizations that had no comparable integration point until recently. The Cloud Security Alliance's AI Safety Initiative treats MCP itself as a new class of dependency, separate from the packages an agent might install through it [12][13][3][4].

The scale involved is why this matters. At Google, a large majority of new code is now AI-generated and approved by engineers, the CSA note says, and a separate study spanning a large population of developers found that AI-authored code makes up a fast-growing share of production commits. That volume puts a plain question on the table: have the controls that verify what lands in a build kept up with how much of that code is no longer written by a person sitting down to write it?

Two named cases show this running in production rather than in a lab. The CSA research note says Elastic's Cloud Control Plane team has Claude built into its CI/CD pipeline for monorepo dependency management, where it reads failed Gradle build logs, works through edit-compile-test cycles on its own, and commits fixes directly to pull request branches. Ramp takes a different approach: background coding agents run inside Modal Sandboxes, and they write code changes back into commits or pull requests with no person driving each step. Both setups give an agent write access to the artifacts that decide what a build pulls in and runs, and write access combined with autonomous decision-making is the condition the rest of this piece works from.

Existing supply chain controls and the agent acting as a contributor

Software supply chain security was built on two assumptions: a person makes a deliberate, reviewable call about which dependency to pull in, and any automated tooling involved stays inside a narrow, well-understood scope. An AI agent selects packages, writes install commands, and commits the result, so it breaks both assumptions at once. The controls were written for a deliberate human decision-maker and scoped to watch a narrow, predictable tool, but an agent is neither.

The CSA AI Safety Initiative lays out where this leaves provenance. Knowing what went into a build now means accounting for the model that generated the code, the agent framework and tool integrations that carried out the installation, and the prompts or context that shaped both of those steps. None of that appears in a conventional dependency scan, which was built to check a package's name, version, and hash, not the reasoning chain that led an agent to choose it.

Governance has not caught up to this either. The CSA note points out that NIST's AI RMF 1.0 applies at the level of a single model inference, while agentic systems create risks at the system level: unintended chains of actions, privilege escalation, prompt injection that hijacks a decision mid-process, all moving faster than a human reviewer can watch. The NIST AI RMF, ISO/IEC 42001, and the EU AI Act contain no reference to "agent," "agentic," or autonomous AI systems. Practitioners disagree: some see a structural inadequacy in the frameworks, others see just a gap that applied interpretation can close. Either way, no major framework currently answers the operational question of how to govern an agent as a contributor to the supply chain.

Hallucinated package names as a predictable, exploitable attack surface

If an agent resolves and installs packages with no person checking each name before it lands in the build environment, a known quirk of large language models turns into a weapon. Models fabricate package names that sound plausible but do not exist, and an agent that trusts its own output will try to install those names. Attackers do not need to guess at this randomly. They only need to find which fabricated names come up often enough to be worth registering.

The technique has a name, slopsquatting, and it works through a simple loop: an attacker sends the same prompt to a popular model many times, watches for fabricated package names that keep reappearing, registers those names on a public package registry, and waits for an agent, or a developer copying an agent's suggestion, to install one. A CSA AI Safety Initiative research note cited an academic study that looked at millions of AI-generated code samples and found that roughly one in five contained a fabricated package name. Nearly half of those hallucinated names reappeared in every single one of ten repeated runs of an identical prompt, and a majority appeared in at least one re-run. That consistency is the whole mechanism: an attacker does not need to guess which names to register, because querying the model enough times turns the stable fabrications into a list.

Hallucination is not the only way agents pull in untrusted code at volume. The CSA note says developers using AI coding tools grab open-source packages fast and at scale, including AI model weights from registries like Hugging Face and container images from sources nobody has vetted, often with no manual risk review in between. Dependency confusion sits alongside this as a related vector: a build system can be tricked into pulling a malicious public package instead of the private internal one it meant to use. That attack predates agents, but it moves faster and triggers more easily when the actor resolving the name is a language model instead of a person reading a manifest line by line.

Documentation and prompt injection as redirection of an agent's install decisions

Catching a bad package name is only half the problem, and an agent that reliably flags suspicious names can still install from an untrusted registry or a hidden index almost without resistance. Whether an install gets caught depends on the combination of harness and model running together, not on the model by itself, and most harnesses simply do not check where a package is coming from.

A systematic evaluation published in July 2026 tested frontier models across multiple scenarios spanning five attack classes, and its central finding cuts against any assumption that a smarter model fixes this: hold the model fixed, swap the harness around it, and the same attack goes from caught to installed. A stronger model is not enough on its own, and neither is a cleverer prompt. Agents follow setup instructions in a way that exposes the gap most clearly. They read a README, a requirements file, or a Makefile and act on what it says without verifying the package names, sources, or versions inside it. The Setup Complete, Now You Are Compromised study found 6,900 requirements.txt files that contain the --extra-index-url pattern, a redirection primitive a model will refuse if you ask for it directly but will carry out once the same intent arrives disguised as an ordinary developer artifact.

Separator confusion shows how much of the name-based vector survives even when the model is careful. An obvious typosquat like tranformers gets caught, but a plausible alternate spelling like azurecore for azure-core slips through, and which one an agent catches depends on the specific harness-model pairing, not the model's general capability. Source-based attacks go further than name tricks and get missed almost everywhere: the same study found agents install from untrusted registries nearly unconditionally on both npm and Cargo, so an attacker's effort spent crafting a plausible name is largely wasted against a channel most harnesses never check.

None of this is theoretical. A documentation-change pull request labeled "docs: readme" on the Ultralytics repository, which draws millions of monthly PyPI downloads, was used to ship crypto-miner releases through its GitHub Actions workflow. The change that compromised the build was a documentation edit, not a code change and not a new package.

Agent skill ecosystems and the dependency graph SBOMs were not designed to reach

Agent skills, the reusable packages of instructions and capabilities that agents compose and invoke, carry dependencies of their own, but those dependencies rarely have a clear identity, version, or origin attached to them. A skill's transitive dependency graph can span other skills, software packages, and external services, and the SBOM tooling organizations already rely on to track supply chain risk in ordinary code does not capture any of it.

A study of more than 1.43 million agent skills found the core problem: skill metadata is activation-ready, so an agent can pick it up and run with it immediately, but it is governance-poor, so almost nothing about where it came from or what it depends on is recorded in a form a machine can check. Dependencies get expressed in natural language, in plain descriptive text, rather than in a structured manifest, so the SBOM tools built to parse manifests have nothing to parse.

An organization can have a disciplined, mature SBOM practice for every software dependency it ships and still have no equivalent visibility into the skill layer now shaping what its agents actually do and install. The dependency graph has grown a new branch that the existing tooling was never built to see, let alone verify.

Agent-written YAML and CI/CD configurations as a durable, poorly-reviewed attack surface

Agents that write the YAML files behind a CI/CD pipeline do more than install packages now. They are authoring the rules that will govern their own future behavior, and those files spread across organizations with almost none of the scrutiny applied to the code they manage.

The scale here is measurable. An empirical study processed hundreds of thousands of file changes across thousands of pull requests in more than a thousand repositories where AI agents had modified YAML files, so YAML-driven configuration now carries most of how agents alter build and dependency pipelines. A separate prevalence study covering more than 10,000 public repositories found that these agent-written configurations spread as undeclared shared components: a majority of clone pairs cross organizational boundaries, the configurations are rarely revised once copied, and fewer than one percent declare any permission boundary. A file that directly steers an agent with write and execute access is, in most cases, carrying almost no access scoping whatsoever.

That leaves the configuration file itself sitting outside any real management. There is no accepted notion of which version is the approved one, no tamper detection on it, no attribution tracing it back to who wrote it or why. The same research argues that files shaping an agent's dependency suggestions need at least as much supply chain rigor as organizations already apply to ordinary software dependencies. NVIDIA's answer, announced at GTC 2026, is OpenShell: an open-source sandboxed runtime for autonomous AI agents that wraps them in kernel-level isolation governed by declarative YAML security policies. OpenShell is a real step toward containing what an agent can do once it is running, but the policy files that define those boundaries will themselves be written by developers, committed to repositories, reviewed in pull requests, and pushed out through the same CI/CD pipelines this section describes. So OpenShell's policy layer is a new artifact that needs governance, not a closed case.

Between January and February 2026, Check Point Research disclosed an actual remote code execution vulnerability in Claude Code that worked through poisoned repository config files, confirming the risk is not hypothetical; it was fixed in version 1.0.111 and above for the RCE issue tracked as CVE-2025-59536, and in version 2.0.65 and above for a related API key exfiltration issue tracked as CVE-2026-21852. The attack vector in that case was a configuration artifact rather than a package sitting in a registry.

MCP servers and tool integrations as a new class of dependency most inventories miss

MCP servers are the connection points through which an agent reaches external tools and data, and they function as a dependency in every sense that matters for security, yet most organizations are not inventorying them, signing them, or auditing them the way they would a third-party code library. The exposure this creates is already measurable rather than theoretical. Trend Micro found 492 MCP servers exposed directly to the internet with no client authentication and no traffic encryption in place.

That number describes servers sitting open to anyone who finds them, feeding tools and data straight into whatever agent connects, with no check on who is asking and no protection on what travels between them. A traditional SBOM was built to track libraries and packages. It was never built to track a live server an agent calls out to mid-task, and that gap leaves the integration layer, the piece of the supply chain an agent depends on most directly to act in the world, largely unwatched.