The Supply Chain You Cannot See

On March 30, 2026, security researchers discovered that axios, one of the most popular JavaScript libraries in the world, had been compromised. The attack was elegant in its simplicity: a maintainer's account was hijacked, a malicious dependency was injected, and for approximately two hours, anyone who ran npm install on a project using axios downloaded a remote access trojan onto their machine.

Axios has over 100 million weekly downloads. Two hours is a very short window. But in those two hours, the malware self-destructed after phoning home, leaving minimal forensic traces on affected systems. The full scope of the compromise may never be known.

This story would be concerning in any era. But what kept me thinking about it for days afterward was a question that I do not think the security community is asking loudly enough: what happens when the thing running npm install is not a human developer who might notice something strange, but an autonomous AI agent executing a coding task?

The dependency graph nobody reads

Let me start with a confession that probably applies to every developer reading this. I do not audit my dependencies. I have never sat down with a fresh package-lock.json and reviewed every transitive dependency that my project pulls in. Neither have you. Neither has anyone, because the numbers make it impossible.

A typical Next.js application has between 800 and 1,200 transitive dependencies. That means when you run npm install on a new Next.js project, you are trusting hundreds of packages written by hundreds of maintainers, many of whom you have never heard of, to not contain malicious code. Each of those packages can execute arbitrary JavaScript during installation. Each of them can access your filesystem, your environment variables, your network.

We accept this trade-off because the alternative is not shipping software. The entire modern web is built on a foundation of implicit trust in strangers.

Here is what is changing: increasingly, the thing running npm install is not a human developer at all. It is an AI agent. Cursor, Windsurf, Claude Code, Codex, Devin, and a growing ecosystem of coding assistants can scaffold projects, add dependencies, run builds, and execute tests autonomously. When you ask these tools to "add authentication to my app," they might run npm install next-auth without you ever seeing the command.

The human developer who runs npm install has at least a theoretical opportunity to notice something wrong. A package name that looks strange. A dependency they did not expect. A postinstall script that takes too long. The agent has no such intuition. It executes the command and moves on.

Three attack vectors that only get worse with agents

The axios compromise was an account hijacking. Someone obtained the maintainer's credentials and pushed a malicious update. This is not a new attack vector. It has been happening for years. But there are at least three categories of supply chain attacks that become dramatically more dangerous in a world where agents are making software decisions.

Account hijacking

The axios attack illustrates the problem. A legitimate package with years of trust history suddenly becomes malicious because the human behind it was compromised. An AI agent cannot distinguish between "this maintainer pushed a legitimate update" and "this maintainer's account was hijacked 20 minutes ago." The agent sees a trusted package name, a valid version number, and no security warnings from the registry. It installs the package.

Human developers are vulnerable to this too. But humans sometimes notice. A colleague might mention that axios seems to be doing something weird. A security researcher might post on Twitter. An agent running in a CI pipeline at 3 AM does not read Twitter.

Slopsquatting

This is the attack vector that keeps me up at night, because AI agents are both the cause and the victim.

"Slopsquatting" refers to attackers registering package names that AI models tend to hallucinate. Researchers have documented this phenomenon across multiple AI coding assistants. When you ask an AI to help you with a task, it sometimes invents plausible-sounding package names that do not exist. "Try installing python-config-loader" when no such package exists. Attackers monitor these hallucinations, identify the most common fake package names, and register them with malicious code.

A 2024 study found that approximately 5.2% of AI-recommended Python packages and 2.1% of AI-recommended npm packages did not exist on their respective registries. Attackers only need to register those names and wait.

The circular nature of this attack is remarkable. The AI hallucinates a package name. The attacker registers it. A different AI (or the same one, later) recommends that package to a user. The user, or the AI acting autonomously, installs it. Malicious code executes. The AI created the vulnerability and then fell victim to it.

Dependency confusion

This attack exploits the way package managers resolve names. If your company has an internal package called acme-utils and an attacker publishes a public package with the same name, some package managers will prefer the public version. The attacker's code runs instead of your internal code.

Human developers can be trained to recognize this risk and configure their build systems accordingly. AI agents do not understand organizational context. They do not know that acme-utils is supposed to come from an internal registry. They see a package name, they query the public registry, they install what they find.

The trust model is backwards

The current software supply chain trust model is built on three assumptions: trust the registry, trust the maintainer, and trust the version. Every link in that chain has been broken in the past 12 months.

Registry compromises happen. PyPI has seen multiple incidents of malicious packages slipping through. npm has had its share. Even when registries implement malware scanning, attackers find ways around it.

Maintainer compromises happen constantly. The axios attack was one of dozens in 2025 alone. Maintainers get phished. They reuse passwords. They have one bad day and lose access to a package that millions of developers depend on.

Version trust is particularly fragile. We assume that if we pin to a specific version, we are safe. But many package managers resolve dependencies transitively, and transitive dependencies can update even when your direct dependencies are pinned. A single compromised package anywhere in your dependency tree can execute arbitrary code on your system.

Agents amplify every weakness in this model because they operate at machine speed without the natural skepticism that even the most trusting human developer possesses. A human developer who sees an unfamiliar package name might Google it. An agent proceeds.

What I learned evaluating PacMon

I will let you in on something from behind the scenes. A few weeks ago, I evaluated a startup concept we internally called "PacMon" (short for Package Monitor). The thesis was exactly what I have been describing: someone needs to build supply chain security infrastructure specifically designed for AI agents, not just for human developer workflows.

The evaluation did not lead to a new company, and here is why. The landscape is already crowded. Socket, Snyk, Sonatype, Dependabot, StepSecurity, and others have built sophisticated tooling for dependency scanning, vulnerability detection, and supply chain verification. The technology exists.

But when I mapped the features of these tools against the agent use case, I noticed a gap. Every one of them is designed for a human developer workflow. They generate reports for humans to read. They create pull requests for humans to review. They send alerts for humans to act on. They assume a human in the loop who will make the final decision about whether to trust a dependency.

None of them are building for the scenario where there is no human in the loop. Where the agent receives a task, decides it needs a package, installs the package, and continues, all without a human ever seeing which package was chosen or why.

This is not a criticism of these companies. They are solving the problem as it exists today, for the users who need it today. But the problem is evolving. And nobody, as far as I can tell, is building for where the problem is going.

What agent-native supply chain security looks like

If I were designing supply chain security infrastructure for an agent-first world, here is what it would look like.

Content-addressed dependencies. Instead of trusting package names, trust content hashes. A package identified by sha256:a3f2b1c9... cannot be swapped out by a compromised maintainer account. The hash is the identity. This is how Nix and Guix work, and there is a reason those systems have never had a supply chain compromise in their core repositories. The web needs something similar for the agent era.

Provenance attestation that machines can verify. SLSA (Supply-chain Levels for Software Artifacts) already provides a framework for this. A package can include a cryptographic attestation that it was built from a specific source commit, on a specific build system, with a verifiable chain of custody. Today, humans read these attestations when they bother to check. Tomorrow, agents should be required to verify them automatically before installation.

Behavioral sandboxing for first-install. When an agent installs a package for the first time, that package should execute in a restricted environment where its behavior can be observed. Does it try to access the network? Does it read environment variables that contain secrets? Does it write to unexpected locations? The agent (or a security layer protecting the agent) should evaluate this behavior before granting full access.

Reputation graphs that update in real-time. Not just "is this package known-malicious," but "has this package's behavior changed in the last release," "does this maintainer's commit pattern match their historical behavior," "are there sudden spikes in install volume that might indicate an ongoing attack." Signals that update in minutes, not days.

The connection to our broader thesis is direct. In the content layer (web pages, documents, information), we are building structured representations that agents can consume efficiently. In the software layer (packages, dependencies, code), we need structured trust signals that agents can verify efficiently. Both are instances of the same underlying problem: infrastructure designed for human interpretation is insufficient for machine consumption.

The parallel to the publisher problem

In "The Publisher's Dilemma," I wrote about the choice publishers face with AI agents: block them, tolerate them, or cooperate with them. Package maintainers face an analogous trilemma, but the stakes are higher.

Publishers who serve content to agents risk having their work extracted without attribution or compensation. That is an economic and ethical problem.

Maintainers who publish packages that agents install risk having their code executed in contexts they never anticipated, by systems that cannot evaluate trustworthiness. And when a maintainer's account is compromised, the blast radius extends to every agent that trusts their packages.

The difference is stark. A compromised web page wastes tokens. A compromised package executes arbitrary code.

The economics of supply chain attacks are asymmetric in the attacker's favor. Compromising a single popular package provides access to potentially millions of developer machines and build systems. The cost of the attack is low (a phishing campaign against maintainers). The potential payoff is enormous (access to source code, credentials, intellectual property, production systems).

As agents take on more autonomous coding tasks, the attack surface only grows. An agent that can install packages can also install malware. An agent that can execute build scripts can also execute attack payloads. An agent that has access to your codebase has access to your secrets, your infrastructure configuration, your deployment credentials.

What happens next

I do not have a neat solution to offer here. The supply chain security problem is genuinely hard, and it is getting harder as agents take on more autonomous software development tasks. But I can describe where I think this is heading.

The first wave of AI coding tools has operated with implicit full trust. They can run any command, install any package, execute any code. This is unsustainable. As the agent ecosystem matures, we will see a separation between agent capabilities and agent permissions, similar to how mobile operating systems restrict what apps can do even when those apps are installed.

The second shift will be toward verifiable provenance by default. Right now, checking the provenance of a package is optional and rare. In an agent-first world, it will need to be mandatory and automatic. Packages without verifiable build attestations will be treated as untrusted by default, the same way HTTPS-only environments treat HTTP connections.

The third shift will be behavioral baselines. We will start treating packages less like static artifacts and more like executable programs that need to be profiled and monitored. A package that suddenly starts accessing the network in ways it never did before should trigger an alert, whether a human or an agent is doing the installing.

Infrastructure problems are what we build

I have spent the past several months writing about how agents interact with web content: the token waste, the comprehension failures, the publisher dilemma. All of that is about the content layer of the agentic web. This post is about something adjacent but equally important: the infrastructure layer.

When agents are the ones making decisions about what software to run, what packages to trust, and what code to execute, the supply chain becomes an attack surface of unprecedented scale. We have been focused (rightly) on how agents read the web. We need to be equally focused on how agents trust the software they run.

This is not primarily a security problem, though security is involved. It is an infrastructure problem. The infrastructure we have, registries, package managers, trust hierarchies, was built for a world where humans make the final call on what to install. That assumption is no longer valid.

We are building infrastructure for the content layer: structured representations, machine-readable trust signals, efficient formats for agent consumption. The code layer needs equivalent infrastructure. Content-addressed dependencies, provenance attestation, behavioral sandboxing, reputation graphs that update at machine speed.

The axios attack lasted two hours. In an agent-first world, two hours is enough time for millions of autonomous installs. The window is not closing. It is opening wider.

David Hurley is the founder of Plasmate Labs. Previously, he founded Mautic, the world's first open source marketing automation platform. He writes at dbhurley.com/blog and publishes research at dbhurley.com/papers.