Preventing Supply Chain Attacks While Agents Work

AI agents have turned dependency malware from a developer risk into an organization-wide threat. Existing agents may bypass controls, so enforcement needs to reach both the registry and the devices where they operate.

Our initial research shows how concentrated this risk has become. The top 100 publishing identities account for roughly 66% of npm downloads and 75% of PyPI downloads. We also found that coding agents may retry blocked installations through alternative package managers, public registries, binaries, or direct tarball URLs.

This preview examines the evolving software supply chain threat landscape, shares our initial findings, and introduces how depthfirst’s Dependency Firewall extends enforcement from the registry to every device where packages are installed.

Introduction

For years, the advice was simple: don’t open suspicious attachments. Malicious code typically entered an organization through user error or by exploiting a drive-by vulnerability.

That is no longer true when agents pull in code on their own. Tools like Codex, Claude, and Cursor are no longer just for engineers. They are writing software and automating workflows across operations, finance, legal, marketing, GTM, and virtually every other function. For example, when a business user asks an agent to build a slide deck, the agent may run code that pulls in third-party packages—including malicious ones, without anyone realizing it.

This research examines which packages agents install, how attackers can compromise the software supply chain, and why registry controls built for humans become obsolete when agents handle package installation.

Malware moved into trusted dependencies

Hackers have been increasingly targeting the software supply chain. If they can compromise a dependency, build system, or publishing account, malicious code can enter software through something developers already trust and intend to run.

• SolarWinds and Codecov moved the attack into build and CI systems.
• XZ Utils combined long-term project infiltration with malicious release artifacts that did not cleanly match the reviewed source.
• Shai-Hulud stole publishing credentials, poisoned trusted npm packages, harvested more credentials from infected machines, and used them to keep spreading.

Dependencies are now one of the most vulnerable attack surfaces in modern software. Coding agents are expanding that surface in two ways: they make package selection and installation increasingly autonomous, and they are putting code execution in the hands of a much broader, often non-technical audience.

People now use agents not only to build software, but also to create presentations, analyze data, automate workflows, and complete everyday business tasks. As agents make more dependency decisions on users’ behalf, attackers have a much larger opportunity to influence what gets pulled into their environments.

The publishers behind the package ecosystem

When an agent chooses a package, the package name reveals very little about who controls what becomes published.

To understand what sits behind package names, we researched 1,000 high-footprint publisher identities on npm and 1,000 on PyPI. We classified each identity into one of four groups:

1. Solo contributors
2. Corporate-backed publishers
3. Independent open-source teams
4. Automated generators or publishing pipelines

Each group represents a distinct attack surface:

Figure 1. Maintainer identities break down differently across npm and PyPI. npm skews corporate-backed by identity count, while PyPI splits far more evenly between corporate-backed identities, independent teams, and solo contributors.

The differences become interesting when we look beyond identity count.

• npm is mostly corporate-backed by identity count is 54.9%. Headcount is not the same as reach, and most downloaded packages are managed by individuals or small teams.
• PyPI has no majority owner. Corporate-backed identities lead at 37.5%, but independent teams (35.4%) and solo contributors (24.8%) are close behind. There is no single publisher type for defenders to focus on.
• Automated publishers are rare but can operate at enormous scale. They represent just 2.3% of PyPI identities, yet some individual automated publishers are responsible for hundreds of packages. Compromising the system behind one of these publishers can affect a much larger package footprint than compromising a typical human maintainer.

The security control that works for one publisher may do little for another. A hardware key can protect a solo maintainer from credential theft, but it does not protect a release workflow with a poisoned cache or compromised workflow. An automated publisher may have no human login to compromise at all, shifting the attack surface to the infrastructure generating and releasing its packages. An attacker could exploit a vulnerability in such a system to publish a malicious package.

Figure 2. A single publishing identity can be responsible for hundreds of packages. The chart shows package associations within the top-10,000 package cohorts.

The largest identities show the scale of that reach. Within the cohort, npm’s types is associated with 451 packages, while sindresorhus is associated with 364. On PyPI, vemel is associated with 479 generated packages and Microsoft with 306.

Coding agents expand the target audience

Until now, most dependency installs have occurred in environments security teams already consider part of the software development stack: developer laptops, CI/CD pipelines, build servers, and artifact repositories.

Coding agents have extended package execution beyond engineering teams. Lawyers, marketers, and recruiters are using tools like Codex, Cursor, and Claude Code on a daily basis to build internal tools.

These may run on laptops with active browser sessions, sensitive documents, SSH keys, SaaS tokens, or cloud credentials. Departmental workflows expand the attack surface, connecting to CRMs, accounting systems, contract repositories, or data warehouses.

Consider the following sequence:

1. A publisher account, build workflow, or generator is compromised
2. The poisoned package enters a dependency graph directly or transitively
3. The agent installs it while completing an ordinary task (for example creating a powerpoint deck for a lawyer or performing data analysis for an investment banker)
4. The attacker compromises the machine, being able to steal sensitive documents, credentials to critical systems, essentially anything that lives on the machine.

No prompt injection is required here. The agent behaved as intended and became the delivery mechanism for malicious code.

Configuring a custom firewall registry is not enough

We tested dependency controls against the question: What happens when policies are enforced for coding agents?

Across the tools we evaluated, enforcement depended on routing installs through a controlled path. Some require developers to prefix the install command. Others use shell aliases or PATH shims backed by a local proxy. Once invoked, they can inspect direct and transitive dependencies. Interestingly, any process that bypasses that path also bypasses the policy, including direct binaries, IDE subprocesses, and agent sessions that don’t load the shell integration.

Other tools rely on environment variables to route traffic through an MITM proxy that blocks prohibited downloads, but agents can override these settings as easily as humans. When an install fails, they may keep troubleshooting until it succeeds, unintentionally bypassing the control with several possible workarounds. Some examples are the following:

• Setting a local .npmrc with a mirror
• Resetting to default config variables
• Unsetting environment variables
• Rewriting metadata files

Some solutions have even attempted to create a full network driver with client-side rewrite logic. However, these are not fully comprehensive and have various bypasses, such as direct tarball installations and mirror registries.

Enterprise impact

depthfirst’s Dependency Firewall enforces package policies at two layers: the registry, through upstreams such as JFrog Artifactory, AWS CodeArtifact, or Sonatype Nexus, and the machine where the AI agent is being run.

We designed the device layer around three requirements:

1. Generalize across ecosystems (Java, JS/TS, Python), package managers (Yarn vs NPM vs Bun) and versions (8.x.x vs 9.x.x)
2. Capture package traffic system-wide rather than relying on a specific application, or shell integration
3. Integrate easily without changing developers’ installation workflows

To meet these requirements, we built the device layer as a network extension we call Device Firewall. On macOS, enabling or disabling this extension requires administrator approval.

Since many developers may hold local admin on their laptops, we support MDM integration so removal of Device Firewall can be blocked or flagged.

Once active, it enforces policies at the network layer, independent of the package manager or process initiating the request. On Linux, the architecture follows a similar enforcement model using eBPF.

Package managers share one trait in common: they emit HTTP requests to fetch the data. Therefore, enforcing policy at this shared layer provides an optimal point where traffic can be identified, intercepted, and routed for inspection.

Because enforcement operates at the device level, this applies independently of the shell, IDE, package manager, or agent initiating the request. Changing or disabling it requires administrator approval or an authorized device-management policy.

Once installed, Device Firewall requires no change to existing workflows. Developers continue using the same commands while registry traffic (e.g. requests to registry.npmjs.org) is transparently routed through firewall.depthfirst.com for policy enforcement.

The same approach is supported on Windows. On both macOS and Windows, organizations can deploy and manage Device Firewall centrally through MDM, protecting every developer and AI user without adding friction to their workflow.