在人工智能（AI）生态系统快速壮大的同时，攻击者正优先盯上那些最薄弱却能造成最大伤害的环节。近期发生的 TeamPCP 攻击事件表明，相较于 AI 应用程序本身，支撑其运行的“软件供应链”和 AI 中间件已成为多么危险的目标。
此次攻击针对的是开源安全扫描器“Trivy”、Checkmarx 应用安全平台，以及通过单一接口连接 100 多个大语言模型（LLM）调用的开源 Python 库 LiteLLM 等。据报道，尤其在被确认为恶意版本的 LiteLLM 1.82.7 和 1.82.8 中，植入了高度混淆的多阶段凭据窃取代码和释放器（dropper）。
问题更严重的原因在于开发环境的结构。通常，开发者账户、云基础设施和 CI/CD 系统会频繁共享敏感认证信息和访问权限。因此，即使像 LiteLLM 这样的单一工具被攻破，攻击者也能在 Kubernetes 集群内横向移动，将数据外泄至外部域名。对于一直基于信任来同时运营安全工具和开发基础设施的企业而言，损失范围——即所谓的“爆炸半径”——必然会扩大。
新情况在于“AI 中间件”已成为核心基础设施
软件供应链攻击本身并不陌生。不过，有分析认为此次案例与当年的 SolarWinds 事件性质不同。原因在于攻击者将安全及开发基础设施武器化，并以需要高权限的工具为跳板，直接瞄准了运行环境的机密信息。结果导致不仅生产环境的秘密值（secrets）可能被访问，而且被窃取或遭勒索软件攻击的可能性也随之增大。
本文原作者、Secure Code Warrior 联合创始人兼首席技术官 Matias Madou 指出，企业现在应将 AI “中间件”视为核心基础设施。这些充当抽象层的工具处于数据流中心，会持续处理 API 密钥、环境变量、模型调用信息等敏感数据。这意味着，即便在 AI 治理体系中，也应当将其作为高风险组件进行管理。
特别是，有观点要求企业引入的 AI 治理政策应被设计为持续监控 LLM 集成基础设施中出现的异常外部连接、数据泄漏尝试以及未经授权的插件使用情况。这意味着仅仅制定模型使用规则，已难以阻止实际攻击。
数小时内即可造成数千次暴露……“事后应对”为时已晚
此次攻击仅在数小时内就可能造成数千次潜在入侵，这一点也敲响了警钟。这表明，仅靠出现异常迹象后再应对的传统方式，已难以保障 AI 安全。因为一旦攻击开始，其速度和自动化水平极高，很难跟上损害扩散的步伐。
应对措施方面，首当其冲的是强化依赖项更新控制。相关说明指出，应应用“依赖项锁定（dependency pinning）”以防止自动更新直接执行，同时实现秘密信息管理体系的现代化，并对访问密钥适用“最小权限”原则。将管道权限限制为仅执行经批准的任务列表，也是同样的思路。
对模型上下文协议（MCP）代理的可视性和控制也成为核心课题。有观点指出，此次损害扩大的背景在于，未文档化的 MCP 插件可能被利用。这意味着，内部连接性强、自主性高的 AI 工具，其首要任务是明确掌握哪些插件已连接、它们以何种权限运行。
开发者教育与规章完善是最快的防线
专家们认为，不应将 AI 安全仅视为安全团队的问题。开发者能够持续学习最新的 AI 安全问题，并能安全地审查工具输出和代码变更，才能真正形成防御能力。尽管传统开发方式正在迅速改变，但代码审查能力、批判性思维以及理解业务背景的能力，依然被评估为至关重要。
在企业层面，也需要一套能够追踪哪位开发者使用何种 AI 工具编写了何种代码的控制体系。有解释指出，随着 AI 编码工具使用量的增加，需要一种能够同时管理提交历史、工具参与范围以及开发者安全熟练度的“统一控制面”。
组织的安全规章也应当根据 AI 时代的需求进行重写。分析指出，仅具备 AI 使用指南、按工具细分的具体规则以及最低限度的安全编码标准，就能在初期减少相当多的风险。也有警告称，在等待立法或监管完善的期间，基于 AI 的入侵可能抢先到来。
AI 安全的焦点已不再是模型性能本身。在实际市场中，连接并运营 AI 服务的供应链、中间件和开发管道正成为新的“核心战场”。如果企业忽视这一点，攻击的速度很可能与 AI 创新的速度并驾齐驱。
TP AI 注意事项 本摘要使用了 TokenPost.ai 基础语言模型。正文主要内容可能被遗漏或与事实不符。