Writing · July 2026

Your AI Tools Are the Attack Surface Now

AI coding tools didn't create supply-chain risk. They moved the blast radius into developer and build environments.

The axios compromise matters here because it landed in developer and build environments that now run agents, not just editors and scripts.

A poisoned package does not need to reach production first if it can reach the workstation with source, shell access, package tokens, cloud CLIs, MCP config, browser sessions, and agent permissions.

In the Axios case, an npm maintainer account was compromised. Malicious axios versions were published. A hidden dependency, plain-crypto-js, carried a cross-platform remote access trojan. The attack used a postinstall step, which is exactly the kind of thing developers have trained themselves to ignore because most installs are boring.

A short exposure window is still enough time when half of organizations adopt a new third-party library version within a day of release.

That is the new attack surface. Not AI in the abstract. The local environment where AI tools act.

The Target Moved

Classic supply-chain defense asks whether malicious code can ship to production. That is still the right question. It is no longer the only question.

A compromised dependency used to get a few common chances: run during install, read environment variables, inspect the current project, maybe phone home. Those were serious already. AI coding tools raise the value of the same foothold because the environment now has tools, credentials, and permission paths attached.

The package does not need to own production if it can own the workstation that can later deploy, push, fetch secrets, trigger CI, or hand an agent trusted context. It can look for credentials. It can tamper with generated code. It can poison context that an assistant will later treat as project truth. It can create instructions that look like documentation. It can wait for the human to ask the agent to do the next privileged thing.

A malicious MCP tool description, README, issue body, dependency comment, or fixture can become an instruction path if the agent is allowed to treat untrusted text as trusted work context.

Three Failure Modes Are Converging

The first failure mode is old-fashioned package compromise. Axios is the clean example: compromised publishing path, malicious dependency, install-time execution, credential exposure risk, and remote access.

The second failure mode is malicious developer content. Jamf has documented attacks that abuse Visual Studio Code workspace trust and task execution. The repo looks like work. The editor asks whether you trust it. The task runs. That was already a bad pattern before agents started reading repos for intent.

The third failure mode is agent-context compromise. Research on AI-assisted development tools and MCP clients has shown that prompt injection can move through tool descriptions and other context channels. Separate MCP safety work demonstrates MCP-enabled attacks involving malicious code execution, remote access, and credential theft. A remote-MCP measurement study found 7,973 live servers, with 40.55% exposing tools without authentication; every one of 119 testable OAuth-enabled servers had at least one flaw.

The common target is the developer environment.

CVE Scanners Are Necessary And Late

CVE scanners are useful. They are also designed around a slower kind of truth: a vulnerable component is known, named, assigned, indexed, and then detected.

That does not cover the first hour of a malicious package. It does not cover a maintainer account that just shipped a bad version. It does not cover a prompt injection hidden in a tool description. It does not cover a repo that weaponizes a trusted editor workflow. It does not cover an MCP server that is not "vulnerable" in the traditional sense, but is simply too powerful for the context where it runs.

This is why behavioral controls matter. The question is not only "is this dependency known-bad?" It is also "what did it try to do after it arrived?"

If your defense cannot answer those questions, it is not a gate. It is a report.

What A Real Receipt Blocks

A receipt is not a pretty log. It is the record that lets you prove what happened and where the run stopped.

For this class of attack, the receipt should make the boring controls visible: package scripts blocked by default, credential paths denied, tool permission separated from untrusted text, outbound hosts surfaced, and new packages, scripts, editor tasks, MCP servers, or network destinations shown as a diff.

It can be small:

run: dependency-update
scope: workspace
attempted:
  - npm install [email protected]
denied:
  - lifecycle script: postinstall
  - read: ~/.ssh/*
  - read: ~/.config/cloud/*
  - outbound: unapproved-host.example
allowed:
  - registry fetch: registry.npmjs.org
  - mcp tool: filesystem.read ./src
exception:
  - none
verdict: blocked before agent context

None of that is exotic. Most of it is unglamorous configuration and a little discipline. That is the uncomfortable part: the gap between "defenses exist" and "defenses are deployed" is usually not research. It is an afternoon nobody has budgeted.

The Practical Minimum

Start with the controls that block the common paths.

npm config set ignore-scripts true

The more useful the tool becomes, the less acceptable ambient authority gets.

The Floor