Supply Chain Risk From Agent-Pulled Dependencies

When a human developer adds a dependency, the act contains a moment of deliberate scrutiny. When an AI agent does it, that moment is compressed or absent entirely. The result is a supply chain attack surface that expands in kind: hallucination-driven slopsquatting, skill marketplace poisoning, and sub-hour malicious releases all exploit the gap between agent speed and human-grade verification. Understanding these mechanisms is the prerequisite to closing that gap.

How autonomous agents pull dependencies differently than humans do

A human developer installing a package performs at minimum a sequence of lookup behaviors: confirming the package name against the registry, reading a README, scanning recent download counts or issue trackers. These actions create friction. That friction is not incidental. It is a control surface. The human checks because the human is accountable for what enters the build.

An agent in a code-generation or task-execution loop resolves dependencies at runtime, often in a single automated step. The agent names a package, calls a tool, and the package is fetched. There is no confirmation gate between the name and the fetch. The deliberation that a human performs is compressed into a model inference, and the model produces a plausible string rather than a verified reference.

The critical step is translation. Agents receive instructions in natural language and convert them into specific package names or registry calls. That conversion is where hallucination enters. An agent tasked with integrating a service may produce a package name that sounds correct but does not correspond to any library that exists. The name is not a typo of something real. It is a fabrication produced by the model's probability distribution. Once that name leaves the model, it becomes a query against a live registry. The registry answers, and the pipeline continues.

This inversion matters. Traditional dependency selection placed a human's judgment between intent and installation. Agentic resolution replaces judgment with generation. The mistake is no longer a human error to be corrected but a distributional property of the model itself. Every subsequent threat in this article exploits that property.

Slopsquatting: how hallucinated package names become an exploitable attack vector

Slopsquatting is the practice of registering package names that AI models are known or likely to hallucinate, so that when an agent resolves a fictional dependency, it fetches a real but malicious one. The term captures the mechanism precisely: the AI's output is slop, and the attacker squats on the names that slop produces. No typo from a human is required, and no legitimate package is compromised. The attack exploits the generative nature of the agent's output.

The structural asymmetry distinguishes slopsquatting from its older cousin, typosquatting. Typosquatting depends on a human mistyping a known name. Defenders can enumerate plausible typos: they can pre-register or block the likely variants of popular packages. The attack space is finite and, in principle, mappable. Slopsquatting targets names the model generates, and those names vary by prompt, model version, and context. The space of hallucinated names is large and not fully enumerable in advance.

Attackers also hold an intelligence advantage. They can probe a model repeatedly with varied prompts to harvest likely hallucinated names before registering them. The defender cannot enumerate what the model will produce under all possible instructions. The attacker can. This asymmetry means the cost of offense is a few registry submissions, while the cost of defense is an open-ended problem of predicting model behavior.

The malicious package, once fetched, executes at install time. In agentic pipelines, that execution often occurs in a privileged or networked context: a CI runner, a sandbox with cloud credentials, an environment that can push to production. The payload inherits whatever authority the agent has been granted. Slopsquatting thus converts a model's probabilistic error into code execution. The mistake is baked into the probability distribution, not a one-off error. It will recur.

Skill and plugin marketplaces as a second-order dependency supply chain

Package registries are not the only dependency channel agents use. Agents also operate through skill marketplaces, plugin stores, and tool registries, where the unit of distribution is not a library but a callable capability. These ecosystems have markedly less vetting infrastructure than established registries like PyPI or npm. The differential is structural, not incidental: the major registries have spent years accumulating abuse-detection tooling, maintainer verification, and community flagging. Skill marketplaces have not had time to build equivalent defenses.

A malicious skill or plugin is architecturally more dangerous than a malicious package. The unit of distribution is designed to be invoked repeatedly and with elevated context. It can exfiltrate conversation history, modify agent memory, or chain into further tool calls. A malicious package executes once at install time. A malicious skill persists as a callable capability that the agent reaches for throughout its work.

Marketplace poisoning can happen at registration, when a bad actor submits a malicious skill, or after registration, when a legitimate skill is updated to include malicious behavior after it has accumulated trust or star ratings. Both vectors are familiar from package registries, but the skill layer compounds them. Skills are often closed-source or partially opaque: an agent invokes them via API, so static analysis of the dependency's code is not always possible. The agent may select a skill based on a description string or a semantic similarity match, not on a verified identity or cryptographic provenance signal.

The opacity is the point. In the package ecosystem, a suspicious dependency can at least be inspected. In the skill ecosystem, the code may never be visible. The agent selects on the basis of what the skill claims to do, and the marketplace's discovery mechanisms are themselves manipulable. The vetting gap is not a temporary deficiency. It is the current state of the ecosystem.

The threat has already materialized. On May 11, 2026, two PyPI packages, mistralai and guardrails-ai, were compromised in a coordinated supply chain attack 2[2]. The incident demonstrates that the boundary between package registries and agent-facing ecosystems is not clean. The same agent that resolves a package may also invoke a skill. Both channels need the same scrutiny, and only one has had it.

Sub-hour malicious releases and the window agents cannot see

A different attack vector operates on the dimension of time. In a well-documented pattern, attackers inject malicious code into a legitimate package for a narrow window, sometimes less than an hour, before the package is pulled or the maintainer account is recovered. Human developers who pin versions or review changelogs may never encounter this window. Agents that run continuously and resolve latest versions on demand may fetch exactly within it.

This is the "right package, wrong moment" problem. The package is legitimate, the maintainer is trustworthy, and the version is real. The vulnerability is not in identity but in timing. Agents in production pipelines often resolve dependencies at task-execution time, not at build time. They pull from the live registry state rather than a locked snapshot. A human who updates weekly may find the malicious version already gone. An agent that updates hourly may be the only consumer of the poisoned release.

Compounding the exposure, agents do not inherently notice that a package version they are pulling is hours old with no prior install history. Those signals, which a senior developer might treat as suspicious, are not surfaced to the agent unless explicitly instrumented. The agent sees a valid package name and a valid version and proceeds. The temporal context that would raise a human's suspicion is absent.

The forensic difficulty is also distinct. By the time monitoring catches anomalous behavior, the malicious version may already be gone from the registry. Attribution is harder, and remediation is complicated by the absence of the artifact itself. Investigators are left reconstructing an incident from logs that point to a version that no longer exists. The registry's own history provides no record of what the agent actually downloaded.

Why the traditional verification stack does not transfer cleanly to agent-driven resolution

Conventional supply chain defenses assume a human is present at the moment of dependency selection and can be made to pause. Lockfiles, hash pinning, SBOMs, and code review all operate on that assumption. Agentic resolution breaks it at the architectural level. The pause does not occur, and the controls designed around the pause lose their purchase.

Lockfiles help but are not sufficient on their own. They protect against version drift in subsequent runs, but they do not prevent a hallucinated or malicious name from being written into the lockfile in the first place. An agent that generates and commits its own lockfile closes the loop on human review: the artifact that was supposed to be the checkpoint is itself agent-produced. The review gate looks at the lockfile and sees order, but the order was composed by the same process that produced the hallucination.

SBOMs and provenance attestations face a similar boundary. They address known packages with known identities. They have no answer for a package that did not exist before the agent invented its name and an attacker registered it. The provenance question for a slopsquatted package is not whether it is signed correctly but whether it should exist at all. The verification stack assumes a world of legitimate entities that can be authenticated. Hallucinated names fall outside that world.

Code review gates work when dependency changes are visible in a pull request a human reads. In fully agentic pipelines, dependency resolution may happen in ephemeral environments that produce no durable diff for review. The change exists only in the moment and leaves no artifact to inspect. Review becomes impossible, not because the human is negligent but because there is nothing to review.

The mismatch is not a failure of existing tools. It is a scope boundary. Those tools were designed for a world where humans select dependencies and machines execute them. Agents invert that relationship. The tools remain valuable within their scope. The problem is that agent-driven resolution operates outside that scope, in a regime where selection and execution happen in the same automated step.

Mitigations that address agent-specific resolution behavior

Effective mitigation requires controls that operate at the speed of agents and intercept resolution before execution, not after. A human-in-the-loop approval for every dependency fetch is not operationally viable at agent throughput. The controls must themselves be automated and pre-emptive. They must sit at the resolution step, not the review step.

Against slopsquatting, package name validation against a pre-approved allowlist or a verified registry snapshot restricts the agent to resolving names that already exist in a curated set. Hallucinated names are blocked at the resolution step because they do not appear in the allowlist. Static analysis of agent-generated code before execution can flag any package reference not in the allowlist, as a hard stop rather than a warning. The allowlist moves the verification boundary to the moment of name generation, where the hallucination occurs.

Against skill marketplace poisoning, vendor-pinned skill versions in agent configuration function as version pinning applied to the skill layer. The agent resolves a specific, known version rather than "latest." Capability sandboxing limits the blast radius of a compromised skill by restricting access to conversation context, memory, and outbound network. A skill that cannot see conversation history cannot exfiltrate it. A skill that cannot reach the network cannot phone home. The sandbox does not prevent compromise. It bounds what a compromise can reach.

Against sub-hour malicious releases, publication-age gating blocks agents from resolving any package version published within a configurable recency window, such as newer than a set threshold of hours. The community gains time to flag malicious releases before agents can fetch them. Behavioral monitoring at the agent output layer detects anomalous post-install activity, since the malicious version may be gone by the time forensics begin. Runtime signals become the primary detection surface when the artifact itself has vanished.

Across all three vectors, cryptographic provenance verification, such as Sigstore-style signing, narrows the identity-spoofing surface. It does not address hallucinated names that are legitimately registered by attackers, because a slopsquatted package can be signed by its malicious publisher and still pass provenance checks. Provenance answers the question of who published a package. It cannot answer whether the package should exist. The ecosystem is nonetheless moving in the right direction: analyzing package behavior at publish time, as Socket does by flagging malicious packages within minutes of publication, catches malicious intent in the registry before agents ever query it. These mitigations are partial. They bound the risk rather than eliminate it. That is the honest scope of what is achievable while agents select dependencies at machine speed.