引言
传统供应链风险关注"构建时锁定的依赖是否被篡改"，而 ASI04 关注的是 Agent 在运行时动态发现、加载并信任的组件------MCP 服务器、提示模板、API Schema、注册表条目------是否在信任建立之前就已经被污染。攻击者不需要入侵 Agent 本身，只需要让它"自愿"加载一个看起来合法的恶意依赖。
一、Agent 供应链安全与传统软件供应链安全的区别
理解 ASI04 的第一步，是认识到它并非传统软件供应链安全的简单延伸。两者在信任建立的时机、组件的性质、验证手段和失效模式上存在结构性差异：
| 维度 | 传统软件供应链安全 | Agent 供应链安全（ASI04） |
|---|---|---|
| 信任建立时机 | 构建时（build-time），依赖在 lockfile 中锁定 | 运行时（run-time），组件在执行过程中动态发现和加载 |
| 组件清单 | 静态、可枚举（package.json、pom.xml、SBOM） | 动态、难以完全枚举（MCP 注册表、运行时模板、Schema 端点） |
| 组件的可执行性 | 代码即行为，接口由类型签名定义 | 自然语言描述本身即行为指导，LLM 将描述解释为指令 |
| 完整性验证对象 | 二进制/源码的哈希与签名 | 代码 + 描述文本 + Schema 定义 + 提示模板，均需验证 |
| 攻击面变化 | 依赖替换、typosquatting、构建管道入侵 | 上述全部 + 工具描述注入、模板投毒、Schema 漂移、Agent 卡片伪造 |
| 失效可见性 | 异常行为通常伴随错误或崩溃 | 恶意行为可返回完全正常的成功响应，可见成功掩盖不可见泄露 |
| 影响传播方式 | 单一下游应用受影响 | 一个被污染的组件可级联影响多 Agent 协作链中的所有下游 Agent |
| 验证时机 | 安装前一次性验证 | 每次运行时加载都需重新验证（签名、哈希、SBOM、行为基线） |
| 信任模型 | 信任根 + 传递信任（依赖的依赖） | 零信任 + 每次加载重新证明，注册表存在不等于可信 |
| 典型控制手段 | SCA 扫描、lockfile、私有 registry、构建可复现 | AIBOM、运行时完整性校验、Schema 基线比对、出口监控、供应链断路开关 |
这张表揭示的核心差异是：传统供应链安全的信任是一次性授予的，Agent 供应链安全的信任必须是每次加载时重新证明的。在传统模型中，"这个包在 lockfile 里且哈希匹配"就足够了；在 Agentic 模型中，同一个 MCP 服务器今天返回的工具描述可能与昨天不同，同一个 Schema 端点可能在两次调用之间被篡改，而 Agent 会在没有任何告警的情况下接受这些变化------因为它被设计为信任运行时发现的结果。
二、为什么 ASI04 不同于传统供应链风险
LLM03:2025 覆盖的是静态供应链：模型权重、训练数据、构建时依赖。这些组件在部署前可以被锁定、扫描、签名验证。但 Agentic 系统的根本变化在于：能力在运行时组合。
一个 Agent 可能在执行任务过程中才查询 MCP 注册表，发现可用的支付网关；可能在推理前从外部 CDN 拉取提示模板；可能根据运行时获取的 Schema 定义来决定向哪个 API 请求哪些字段。这些组件不在构建清单里，没有 lockfile，也没有"批准一次就永久生效"的版本锚定。
更危险的是，工具描述本身就是可执行的。在传统 npm 包中，接口由代码签名定义；在 MCP 中，接口包含自然语言描述，LLM 会将其解释为行为指导。攻击者可以只改描述文本、不改任何代码，就改变 Agent 的行为------而代码扫描器不会对描述变化发出任何警报。这正是上表中"组件的可执行性"和"完整性验证对象"两行差异的直接后果。
三、三个真实感极强的攻击场景
场景一：幽灵支付处理器（MCP 工具替换）
一家银行的 AI 助理通过 MCP 注册表动态发现支付工具。攻击者在注册表中投放了一个名为 FakeSwiftGateway 的网关，暴露与合法服务完全相同的接口，返回相同的成功响应。唯一的不同：每笔转账静默扣除 0.5% 流向攻击者账户。
四个月内，47,000 笔转账全部"成功"，客户收到款项，运营仪表盘全绿。累计流失 230 万，直到财务对账才发现异常。Agent 从未验证这个网关的发布者是谁、签名是否有效、是否在批准的 AIBOM 清单中------它只因为"注册表返回了它"就赋予了生产信任。这对应上表中"信任建立时机"从构建时滑向运行时的典型失效。
这个场景的原型在现实中已有对应：npm 上出现的恶意 MCP 服务器冒充 postmark-mcp，秘密将外发邮件的密送副本发送给攻击者。
场景二：被投毒的提示模板（运行时指令注入）
法律 AI 助理每次审查合同时，从外部 CDN 动态拉取审查模板。模板本身看起来完全正常：包含条款分析规则、风险识别指引、摘要格式要求。但模板深处埋了一条额外指令：提取合同当事方、财务金额，写入临时文件。
Agent 不是被"黑"了，而是相信这些指令是受信任的系统行为。律师收到正确的审查摘要，没有任何错误或警告。但 14 天内，每一份经手的并购合同------交易金额、对手方名称、法律策略------都被静默导出。可见的成功掩盖了不可见的泄露，这正是上表"失效可见性"一行的现实写照：传统供应链攻击往往导致崩溃或异常，而 Agent 供应链攻击可以完全隐藏在正常业务输出之下。
场景三：被篡改的 API Schema（数据契约污染）
电商推荐 Agent 在调用商品目录 API 前，动态加载 Schema 定义，用以确定"允许请求哪些字段、允许哪些过滤条件"。攻击者在 Schema 中悄悄加入了一个新参数：user_profile_export，指示 API 在每次商品查询时额外返回用户 ID、邮箱和浏览历史。
推荐本身依然准确，客户看到的商品没有异常。但三周内，超过 80 万份客户画像随正常浏览请求流出系统。攻击者没有入侵商品 API，API 完全按 Schema 行为------被污染的是告诉 Agent"如何调用 API"的那份定义。
这三个场景对应同一条信任失败链：组件被发现 → 完整性未被证明 → Agent 加载 → 行为被污染。不同的只是被投毒的是工具、模板还是 Schema，而共同点是传统供应链的构建时验证机制在此完全缺位。
四、防御的核心：把"发现即信任"变成"证明才信任"
OWASP 给出的缓解措施围绕一个中心原则展开：运行时加载的每一个组件，都必须经过与构建时依赖同等甚至更严格的准入审查。这本质上是用零信任模型替代传统供应链的"一次性授予"信任模型。以下是可操作的控制层级，从准入到运行时监控：
第一层：AIBOM 与准入控制
维护一份 AI 软件物料清单，覆盖 Agent 可能加载的每一个模型、工具、提示模板、Schema 和 MCP 服务器。结合允许列表和源固定，只从预先批准的来源加载组件。未知注册表和浮动源路径不获得任何信任默认值。
关键问题不是"这个组件看起来是否合法"，而是"它是否在批准清单中，且来源是否被固定"。这弥补了上表中"组件清单"从静态可枚举变为动态难枚举所带来的缺口。
第二层：密码学完整性验证
即使组件在允许列表中，也要验证这一份副本是否与组织批准的内容一致。哈希证明内容未变，签名证明发布者身份和批准状态。名称正确、路径正确都不够------完整性证明的是内容本身仍然匹配。
在 MCP 场景中，这意味着在每次连接时捕获完整的工具清单（工具名、描述、参数 Schema、返回类型），与已知基线比对。描述变化不是"正常更新"，而是需要调查的信号。这直接回应了"完整性验证对象"一行的差异：验证范围必须从二进制扩展到描述文本和 Schema。
第三层：Schema 与基线校验
对于 API Schema 和提示模板这类"定义行为规则"的组件，需要将运行时加载的版本与批准基线进行差异比对。一个字段的添加、一条指令的插入、输出形状的细微变化，都可能是污染信号。校验机制应在漂移出现时中止，而不是静默接受。
第四层：运行时行为监控（出口监控）
通过准入和完整性检查的组件仍可能在运行时表现异常。一个恶意支付网关可以返回正常的成功响应，同时在后台窃取资金。因此需要监控：出站调用的目的地是否在预期范围内、返回的数据形状是否偏离基线、是否存在未预期的写入操作。
成功响应本身不是可信证明。幽灵支付处理器的每一笔交易都返回成功。这一层专门针对上表中"失效可见性"的差异------当恶意行为不产生错误时，只有行为监控能发现异常。
第五层：人工审批与供应链断路开关
运行时新出现的、更新过的或结构变化过的组件，不应静默加入信任路径。需要有人审查、批准，并对引入该变更负责。同时，必须存在紧急撤销机制------在发现某个组件被污染时，能够立即在所有部署中禁用该特定工具、提示模板或 Agent 连接，防止损害级联扩散。这对应上表中"影响传播方式"的差异：Agent 供应链的污染会沿协作链级联，因此撤销也必须是全局性的。
五、给开发者的检查清单
在设计和运营 Agentic 系统时，用以下问题做快速自检：
-
这个 Agent 在运行时能加载哪些不在 lockfile 中的东西？ 如果答案是"很多"或"不清楚"，ASI04 的暴露面就已经存在。
-
如果一个已批准的 MCP 服务器今晚被替换成恶意构建，什么机制会注意到？ 如果没有，完整性验证就是缺失的。
-
AIBOM 是从"实际加载了什么"生成的，还是从"打算加载什么"生成的？ 前者才有安全价值。
-
发布者的身份是如何验证的------通过密钥，还是通过名字？ 名字可以被仿冒，密钥不能。
-
成功响应是否被当作安全证明？ 如果是，出口监控和异常行为检测就是必需的补充。
-
你的信任模型是"批准一次、长期有效"，还是"每次加载、重新证明"？ 传统供应链可以承受前者，Agent 供应链不能。
ASI04 的本质不是 Agent 被攻击，而是 Agent 自愿地、合规地、在正常业务流程中 信任了一个不该信任的组件。防御的关键时刻不在模型推理阶段，而在加载决策发生之前的那一瞬间。传统软件供应链安全教会我们锁定构建时依赖；Agentic 供应链安全要求我们把同样的严谨------甚至更强的零信任纪律------延伸到每一次运行时加载。