第一天装的工具第七天偷走 API 密钥：智能体供应链安全怎么设防

一、被忽略的上游：供应链才是智能体安全的“长周期软肋”

讨论智能体安全的文章，大多把火力集中在运行时：共享上下文里的提示词注入、越权调用之后的响应处理、按场景做分类分级治理。这些当然重要，但它们都在回答“攻击发生的那一刻怎么办”。

供应链安全回答的是另一个问题：风险在你还没运行任何东西之前就已经埋好了，而且可能埋很久。智能体天然依赖三类外部组件——模型接入、API 调用、扩展工具（尤其是 MCP 生态里的各类服务器和工具）。每引入一个第三方组件，就是把一份信任委托出去；而这份信任会随版本更新不断延续，一旦某次更新被污染，风险就会“延迟引爆”——工具先安全，更新后恶意。

这不是耸人听闻。W3C Web 演进系列活动中杨琼谦的演讲材料《AI智能体的安全挑战及应对建议》给出了一个非常具体的场景（"地毯式骗局"）：用户在第一天批准安装了一个看似安全的工具，到了第七天该工具版本更新，它悄悄地将 API 密钥重定向给了攻击者。攻击者先通过看似正常的工具诱导用户安装并建立信任，之后在远程更新中植入恶意代码、篡改工具描述，把它变成恶意工具。

这正呼应了网信办《智能体规范应用与创新发展实施意见》第 9 条“加强供应链安全”的要求：制定智能体开发、部署、应用、维护等全周期安全规范，加强模型接入、应用程序接口调用、扩展工具使用等环节安全管理，并探索建立智能体供应链安全信息共享和预警机制。

二、三种典型的供应链攻击形态

结合上述演讲材料，供应链相关的攻击至少有三种形态值得注意：

1. 工具投毒攻击。攻击者在工具层面做手脚：指示模型直接访问、提取和传输敏感数据并向用户隐藏这些操作，同时隐藏工具参数、用简单的 UI 表示输出——用户看到的内容和 AI 实际做的事情脱节。这意味着“界面上看起来正常”根本不构成安全证据。

2. 影子攻击（MCP 场景）。当多台服务器连接同一客户端时，恶意服务器能够污染工具描述，窃取其他可信服务器的数据并实现身份验证劫持。MCP 协议的“共享上下文机制和工具描述的全局可见性”是把双刃剑：恶意服务器可以借此把行为逻辑注入整个系统，形成隐蔽且跨服务器的攻击链。很多文章讨论过共享上下文注入，但影子攻击的特殊之处在于它利用协议设计本身，攻击面从单个工具扩展到了整个客户端会话。

3. 地毯式骗局。即上文第七天偷 API 密钥的场景。它的要害不在技术多复杂，而在于时间维度：准入审批时它是干净的，危害在后续版本更新中才出现。如果你的治理流程只有“接入时审一次”，那这道防线对这类攻击形同虚设。

IDC 在《智能体安全：2026年AI落地过程中最容易被低估的治理挑战》中也明确指出：智能体的开发与运行依赖大量第三方组件与工具链，软件供应链风险随之放大；企业需要覆盖大模型、知识库、RAG、Skill、思维链、MCP、API、第三方工具等核心组件的全流程检测与管控。IDC 的调研还显示，约 64% 的企业已经在生产环境中发现未授权的智能体或自动化脚本运行在关键业务流程中——连“谁在环境里跑”都搞不清楚，供应链治理更是无从谈起。

三、一条“接入—审批—更新—预警”的治理链路

《实施意见》的三个条款其实正好构成一条链路：第 9 条给出供应链全周期规范的纲，第 8 条要求权限管理、行为控制等内生安全能力，第 11 条提出分类分级治理框架（敏感领域备案检测召回，低风险领域合规自测与分发平台管理）。据此可以把治理拆成四个环节：

1. 接入：只引入“可追溯”的组件

• 来源白名单 + 签名校验。优先从企业认可的分发渠道或经过认证的来源引入工具；《实施意见》第 12 条提出推动认证与检测结果互通互认，可作为选择依据。
• 锁版本 + 记录哈希。接入时固定版本号，记录工具描述、权限声明、依赖清单的哈希基线。没有基线，后续就无从判断“更新改了什么”。
• 最小权限声明。工具申请的权限范围必须显式列出（读哪些数据、访问哪些 API、是否外发网络请求），接入审批只对声明范围内的功能放行。

2. 审批：审的不只是代码，还有“工具描述”

• 重点审查工具描述与实际行为的一致性。工具投毒和影子攻击都利用了描述层的操纵，因此审批材料应包含工具描述文本本身，并检查是否存在引导模型绕过用户感知的措辞。
• 对 MCP 类客户端，限制工具描述的全局可见性带来的交叉影响：不同信任级别的服务器尽量不接入同一客户端会话，降低“一台被污染、全场遭殃”的连带面。
• 参照《实施意见》第 6 条“明确决策权限”，把工具的能力映射到决策边界上：哪些操作仅限用户本人决策、哪些需用户授权、哪些可自主执行，审批时逐项落档。

3. 更新：把每次版本变更当作一次重新准入

这是最容易被省略、也是“地毯式骗局”直接命中的环节。

• 更新≠自动放行。任何版本更新都触发差异审查：对比新旧工具描述、权限声明、依赖变更、网络行为差异。描述被改写、新增外发域名、权限悄悄扩大，都是红旗。
• 行为基线比对。在测试环境中运行更新后版本，比对 API 调用目标、数据流向是否与基线一致。密钥被重定向，最先暴露的往往是外联目标变化。
• 凭证隔离。工具调用使用的 API 密钥应按工具隔离、限定作用域，并配置异常用量告警。即使某个工具被污染，密钥的爆炸半径也被限制住。

4. 预警与响应：让风险信息流动起来

• 接入《实施意见》倡导的供应链安全信息共享和预警机制：一旦社区或厂商披露某个工具存在投毒行为，能在小时内而不是月内完成自查、下架和密钥轮换。
• 结合第 10 条要求，建立常态化风险识别、预警及干预机制，保留人机协同审核和拦截阻断的处置通道。
• 对敏感领域，参照第 11 条做好备案、检测和问题产品召回的准备；低风险领域至少做到合规自测和分发渠道留痕。

四、适用范围与局限

这套链路适用于企业自建智能体平台、接入 MCP 生态或大量使用第三方工具/API 的团队；对个人开发者，至少可以落实“锁版本、审更新、隔离密钥”三件事。

但也要坦率承认局限：

• 哈希和差异审查挡不住语义级的恶意逻辑。一次更新里一段看似合理的代码路径变化，人工审查未必能识别其真实意图，工具描述的语义操纵更难自动化判定。
• MCP 的共享上下文机制是协议层设计，在客户端侧做隔离只能缓解、不能根除，依赖协议标准本身的演进。
• 预警机制依赖信息披露的速度和广度，在共享机制成熟之前，长尾工具的风险窗口期客观存在。
• 消毒后的供应链仍要面对运行时风险（提示词注入、幻觉、多智能体协作失效），供应链治理是必要条件而非充分条件。

五、小结

智能体供应链安全的核心矛盾是：信任的授予是一次性的，而风险是随版本更新持续注入的。“第一天干净”永远推不出“第七天干净”。把《实施意见》第 9 条的“全周期安全规范”翻译成工程语言，就是让接入有基线、审批有材料、更新有门槛、风险有通道——四环缺一，攻击者只需要一次看似无害的版本更新。

参考资料

以下链接为本文使用的公开资料。事实依据与检索摘录保存在本地记录中；资料内容与适用范围以原始页面为准。

• 智能体规范应用与创新发展实施意见_中央网络安全和信息化委员会办公室
• [\[PDF\] AI智能体的安全挑战及应对建议](<https://www.w3.org/2024/01/webevolve-series-events/annual-2025/slides/qiongqian-yang.pdf>)
• IDC - 智能体安全：2026年AI落地过程中最容易被低估的治理挑战