AI Coding Tools Are Now a Supply Chain Attack Surface

The TrapDoor campaign didn't exploit a vulnerability in any AI model. It exploited the absence of any governance over what AI models are allowed to read.

Every developer on your team is collaborating with an AI. GitHub Copilot, Cursor, Claude -- they sit in the IDE, read project context, and suggest code in real time. That productivity story has been running for two years. The security story arrived this week.

TrapDoor, a campaign documented by The Hacker News on May 25, distributed 34 malicious packages across npm, PyPI, and Crates.io -- the three registries developers pull from daily. These packages weren’t generic malware. They were precision-built to target AI-assisted development environments. And the attack they carry out doesn’t compromise the AI model itself. It poisons the configuration file that tells the AI what to do.

That distinction is the reason TrapDoor is harder to detect than most supply chain attacks -- and why it exposes a governance gap that predates this campaign and will outlast it.

What TrapDoor Actually Did

The attack chain starts where most enterprise security controls aren’t looking: the open-source package registry. A developer installs a malicious package -- a convincing lookalike to a legitimate dependency. After installation, rather than executing a payload directly, the package modifies the project’s `CLAUDE.md` file.

CLAUDE.md is the configuration file that AI coding assistants read to understand project context. It’s essentially a briefing document: here’s what this project does, here are the conventions to follow, here’s how to behave. Modify that file, and you modify what the AI does -- without touching the AI model at all.

Once the configuration is poisoned, the AI coding tool begins redirecting requests toward attacker-controlled infrastructure. In the process, it exfiltrates credentials and environment variables that happen to be in scope when it reads project context. GitHub tokens, API keys, AWS credentials, SSH keys -- anything the tool was reading as part of normal operation goes out the door.

The model wasn’t compromised. It followed its instructions. From the model’s perspective, everything was normal.

The Governance Gap TrapDoor Found

To understand why this attack works so well, you need to understand how AI coding tools are provisioned in practice. When a developer’s IDE integrates an AI assistant, that assistant receives broad read access to project context -- source files, configuration files, environment hints, documentation. That breadth is intentional. The more context the model has, the better its suggestions.

That design creates a data channel. Everything the AI reads becomes, in effect, data in transit to an external service. In most development environments, that channel is governed by nothing more than the developer’s agreement to the AI tool’s terms of service. There is no explicit access policy defining which files the AI can read. There is no egress control defining what data can leave the development environment. There is no alert when the AI makes an unexpected outbound connection.

The CrowdStrike 2026 Global Threat Report documents a 3x increase in AI supply chain attacks via third-party models since 2022. TrapDoor fits that escalation pattern precisely. The attack surface it exploited -- the ungoverned data channel between developer environments and AI inference -- has existed for as long as AI coding tools have existed. TrapDoor is the first campaign I’ve tracked that weaponizes it through configuration file manipulation, which is a meaningful escalation: the delivery mechanism is invisible to signature-based detection, and the attack appears as normal AI behavior in every log that captures it.

The Compliance Exposure Nobody Has Priced

This is the part of the TrapDoor story that I think is under-discussed: the compliance dimension.

AI coding assistants in regulated industries routinely read sensitive context. Defense contractors use them to write code that handles Controlled Unclassified Information. Healthcare developers use them in environments where source code touches PHI. Financial services teams use them in codebases that process personally identifiable customer data.

When an AI tool reads that content and the data channel is ungoverned, the tool is a data egress vector. And when TrapDoor -- or any successor campaign -- manipulates the configuration file that tells that tool what to do, the egress is deliberate and directed.

The Kiteworks Data Security and Compliance Risk: 2026 Forecast Report finds that 63% of organizations cannot enforce purpose limitations on AI agents -- they have no technical control over what the agent does with data once it has access. That number was a governance gap before TrapDoor. After TrapDoor, it’s a documented attack surface.

Logging the activity after the fact does not satisfy the access control requirements under CMMC, HIPAA, or ITAR. The requirement is to prevent unauthorized access, not to record it.

The Architectural Response

Zero-trust content governance applied before an AI tool reads sensitive data is the response that contains the damage when supply chain attacks succeed. Access policy at the data layer operates independently of whether the AI tool’s configuration has been compromised -- because the control isn’t in the AI tool’s configuration. It’s in the content infrastructure the AI tool is reading from.

Platforms like Kiteworks enforce attribute-based access controls at the data layer: the AI tool’s identity, scope, and authorization level are verified before any content is returned, regardless of what the tool’s configuration file says it’s allowed to do. A poisoned CLAUDE.md file can redirect the tool’s requests -- but those requests still hit a governance layer that evaluates them independently.

The principle extends beyond TrapDoor. Any AI tool with read access to sensitive content is a potential data channel. The question isn’t whether to trust the tool -- it’s whether the data that tool can access is governed independently of the tool itself.

What TrapDoor Changes About the Developer Security Conversation

Before this week, the AI supply chain risk conversation was largely theoretical for most security teams. After TrapDoor, it has a specific attack pattern, a documented delivery mechanism, and a confirmed payload. The conversation is no longer hypothetical.

The organizations that will contain the next campaign like this are the ones that have already asked: what can our AI coding tools read, and what happens when what they read goes somewhere it shouldn’t?

The governance gap TrapDoor exploited existed before this campaign. It will still be there after the immediate response to TrapDoor fades.

If this is useful, subscribe to get the next one.