软件供应链的信任模型正面临一场前所未有的结构性挑战。一场代号“TrapDoor”的协调供应链攻击，同时对npm、PyPI及Crates.io三大主流包管理器发难，部署了34个恶意包。此次攻击的目标明确：窃取加密货币开发者、AI从业者及安全研究人员的钱包密钥、SSH凭证及云服务认证信息。但真正让安全界警觉的，是其攻击链中的全新环节——将AI助手作为跳板。

传统供应链攻击往往聚焦于代码仓库的污染或依赖包的后门植入。而此次TrapDoor攻击采用了一种更为隐蔽的手段：攻击者向流行开源项目提交伪装成无害贡献的Pull Request，其中嵌入了被篡改的CLAUDE.md及.cursorrules配置文件。当开发者克隆这些被污染的仓库，并启动Claude Code或Cursor等AI辅助编程工具时，AI智能体将这些文件当作权威指令执行。攻击者利用AI助手对配置文件“无条件信任”的机制，诱使智能体在开发者不知情下，运行包括窃取凭证、安装恶意包在内的危险命令。

这一机制的本质，属于“AI信任劫持”。在此前，即便代码被污染，开发者仍有机会通过代码审查发现风险。但AI助手的自动执行特性，实际上建立了一条新的攻击信道：攻击者不再需要绕过开发者的逻辑审查，而是直接封装一个AI语境下的“合法指令”，由机器代为决策与执行。目标也不再局限于代码本身，而是向外沿扩展到开发者的数字身份与密钥资产。对于依赖AI辅助编程的大型团队或高安全需求的金融、基础设施项目，这构成了一重软性但持久的威胁。

对于Claude Code及Cursor的活跃用户而言，当前亟需建立一套配置文件安全审查流程。开发者应遵循“最小信任原则”：对所有.clauderules、.cursorrules及类似配置文件实施版本控制签入审查，不允许来自未知贡献者的未审核Pull Request直接落地到工作分支。同时，团队可考虑在Git钩子中预置对配置文件的静态规则检查，标记包含可疑路径、shell执行或网络请求片段的文件，或在沙箱环境中预先模拟配置文件执行效果。对于敏感项目，更应关闭AI助手的自动模式，强制每次配置变动都经人工确认。

这场攻击事件预示着一个新安全轨道的形成——AI智能体成为软件供应链中的新攻击面。从依赖包到IDE插件，再到AI配置，攻击者正持续沿信任链条的最薄弱环节前移。开发者社区与安全厂商有必要尽快将“AI配置验证”纳入标准安全流程，否则TrapDoor只能被视为一场预演，而非终局。