The AI Supply Chain Attack Your Security Team Is Not Modeling Yet

The fastest way into an enterprise codebase right now is not through a misconfigured S3 bucket or a phishing email aimed at a junior developer. It is through the AI tooling that your most senior engineers run with elevated trust, persistent sessions, and direct access to production secrets. The Cursor and Claude Code extension incidents made this concrete: malicious extensions distributed through IDE marketplaces can intercept completions, exfiltrate prompts, and establish persistent footholds before a single line of suspicious code appears in a pull request. If your threat model still treats the model provider as the primary AI risk, you are defending the wrong perimeter.

Companion piece to our broader work on AI-assisted development security. See Supply Chain Attacks & Developer Tooling Security for dependency defenses, automated tooling risks, and governance strategies for CTOs.

Why AI Developer Tooling Is Now a Primary Attack Surface

AI coding assistants sit at an unusually privileged position in the development environment. They read full file trees, hold authentication tokens for version control and cloud providers, and in agentic configurations they execute shell commands. That combination of read access, credential proximity, and execution capability is exactly what a post-exploitation attacker would want to establish manually. A malicious extension delivers it automatically, on every machine that installs it.

The extension marketplace model compounds this problem. Cursor, VS Code, and similar platforms allow third-party publishers to distribute tooling with minimal vetting. A package with a plausible name and a handful of five-star reviews can acquire thousands of installs before any automated or manual review flags its behaviour. The trust signal developers use, install count and publisher name, maps poorly onto actual security assurance.

The Mechanics of an IDE-Layer Compromise

Extension-Based Interception

A malicious extension registered as an AI provider or a completion enhancer can position itself as a man-in-the-middle between the developer's editor and the legitimate model API. It passes completions through transparently while logging every prompt and response to an attacker-controlled endpoint. Because the developer sees normal output, there is no behavioural signal to trigger suspicion.

The exfiltrated prompts are high-value intelligence. Engineers routinely include environment variables, internal API schemas, database connection strings, and proprietary business logic in their prompts. A few days of intercepted sessions from a single senior engineer can produce a near-complete map of an organisation's internal infrastructure.

SSH Backdoor Establishment

More aggressive variants use the extension's execution context to write authorised SSH keys or modify shell profiles. Because many AI coding tools request terminal access to run tests, install dependencies, or execute agent tasks, the permission to run shell commands is often granted by default. An extension that abuses this permission can establish persistence that survives both the IDE session and the extension's own removal.

This persistence vector is particularly difficult to detect because it does not require the extension to remain installed. The backdoor is written once and the extension can be removed cleanly, leaving no artefact in the marketplace or the developer's installed package list.

What Security Reviews Are Missing

Most enterprise security posture reviews assess AI risk through the lens of data governance: what data enters the model, what the model returns, and whether outputs are logged. That framing is appropriate for SaaS model APIs but it does not address the tooling layer at all. The IDE, the extension registry, the MCP server configuration, and the agent's local execution environment are outside the scope of almost every AI-specific security checklist we have reviewed in practice.

Software composition analysis tools are also not keeping pace. SCA pipelines scan dependencies declared in package manifests. An IDE extension loaded through a marketplace UI does not appear in a requirements file or a lock file. It is invisible to the tooling that security teams rely on to detect third-party code risk.

The gap is not a failure of individual security teams. It reflects how quickly AI coding tools moved from experimental to standard practice. Adoption timelines measured in weeks do not leave room for policy frameworks to catch up.

The Governance Controls That Reduce Exposure

Extension Allowlisting

The most direct control is treating IDE extensions as software that requires approval before installation, in the same way that server-side dependencies do. This means maintaining a curated allowlist of approved extensions, enforcing it through device management policy, and requiring a lightweight security review for any addition. The review does not need to be exhaustive. Checking publisher identity, source code availability, and network egress behaviour at install time eliminates the majority of opportunistic threats.

Prompt Traffic Inspection

Organisations running AI coding tools at scale should route completions through a controlled egress point rather than allowing direct developer-to-provider connections. This creates a log of prompt traffic that can be inspected for anomalous patterns, including unexpected data volumes, off-hours activity, or prompts containing credential-shaped strings. It also provides the visibility needed to detect interception, because a man-in-the-middle extension will produce traffic to a second destination that a direct connection would not.

Agent Execution Sandboxing

Agentic AI tools that execute code or run shell commands should do so inside an isolated environment with defined network and filesystem boundaries. Container-based sandboxes with explicit egress rules prevent an agent, or a compromised extension controlling one, from writing to persistent locations or establishing outbound connections to attacker infrastructure. The performance overhead of this approach is low relative to the exposure it closes.

Building a Threat Model That Includes the IDE Layer

The practical starting point is a mapping exercise. Document every AI tool in active use across engineering teams, including the extensions, plugins, and MCP servers attached to each. For each tool, identify what credentials it can access, what commands it can execute, and where its network traffic goes. Most organisations that complete this exercise discover that the actual attack surface is significantly larger than their security team assumed.

From that map, apply standard threat modelling methodology: enumerate the realistic attacker paths, assess the controls currently in place against each path, and prioritise the gaps by likelihood and impact. The IDE-layer paths will almost always surface as high-likelihood and low-control, because the tooling was adopted without a corresponding security review.

The goal is not to slow down AI adoption. Engineers using AI coding tools produce output faster and, when the tools are configured correctly, with fewer classes of error. The goal is to ensure that the security posture review catches up to the adoption reality before an attacker exploits the gap that currently exists between the two.