AI供应链安全（3）：把风险测准——智能体安全检测与评估

锦岳智慧

2026年10月18日 12:09
北京

去阅读

前两篇分别回答了两个问题：第一篇讨论如何把智能体“看见”，解决\"有多少个在跑\"；第二篇讨论如何用 AIBOM 说清构成，解决“每个由什么组成”。但台账建得再全、清单列得再细，都回答不了一个智能体是否安全、能否上线。而检测与评估恰恰是最容易做偏的一环——它看起来最“技术”、投入也最大，却最容易在缺少台账与清单支撑时变成盲测：跑了大量用例、产出大量结果，却既说不清覆盖了什么，也说不清问题该归给谁。

1“全量测一遍”为什么行不通

很多团队启动智能体安全检测时的第一反应是：把所有智能体拉出来，跑一遍通用的大模型安全测试用例。这个做法直观，但通常会撞上三个问题。

对象不确定。一百二十个智能体，每个跑几百条用例，产出几万条结果。看起来工作量饱满，但这些结果里没有一条能落到责任人和业务线上——因为你事先不知道该测谁、测到什么算覆盖完成。

深度不匹配。一个能读写生产数据、可对外发送消息的智能体，和一个只在内部做文档摘要问答的机器人，用同一套用例、同一个频次，是明显不合适的。

结论无处归因。测出一条“提示词注入成功”，接下来怎么办？它属于哪个组件？影响哪几个智能体？该通知谁？要不要阻断上线？如果这些问题答不上来，检测报告就只是一份技术记录，无法支撑决策。

这三个问题里，成本只是表象。真正的症结在于：脱离台账与清单的检测，本质是盲测。这也是第一篇和第二篇必须先于本篇的原因——它们不是铺垫，而是检测能否成立的前提。

1.1　分级决定测什么、测多深

第一篇提出的智能体分类分级，到这里才真正发挥作用。按“数据敏感度 × 动作权限”划分出的核心、重要、一般、试验四个级别，可以直接映射为差异化的检测策略：

核心级——纳入强制检测与变更审批，每次变更必测，上线前需完成全项评估；

重要级——按周期开展常规检测，发生关键变更时追加评估；

一般级——按周期抽检，覆盖基础项即可；

试验级——仅做基础项检测，不占用主要检测资源。

四档策略的差异，本质上是在回答两个问题：检测资源有限时先测谁，以及测到什么程度可以支撑决策。分级不是为了把资产分出高低，而是为了让有限的检测能力投到真正高风险的对象上——对核心级投入不足是失职，对试验级过度投入则是浪费。

1.2　变更决定什么时候重测

第一篇讲过版本快照的六个可变要素——基座模型、提示词、知识库、工具与插件、编排逻辑、权限边界。这六项同时也是检测的重测触发器：

更换或升级基座模型，重测模型层；新增或替换 MCP Server、Skills，重测执行层，且应作为关键变更走审批后复测；调整提示词与知识库，抽测输出层与事实一致性；调整权限边界或编排逻辑，重测越权与级联相关项。

有了这层映射，“每次变更都全量重测”就不再是必选项。更重要的是，它让运行期那些不经过发布系统的变更——改提示词、传文档、运行时挂载新工具——也能触发对应的检测，而不是等到下一次例行评估才被发现。

图 1　检测策略的两个决定因素：分级决定测什么、测多深，变更决定何时重测

2检测对象从哪来：清单给出靶心

检测不是拿着用例集去扫，而是先确定靶心。靶心来自三个输入：构成（第二篇的 AIBOM）、分级（第一篇的资产分级）、变更（第一篇的版本快照）。三者合起来回答一个问题——这次到底要测什么。

图 2　检测靶心的来源：资产台账与 AIBOM 清单共同确定模型层、执行层与输出层的检测范围

按攻击落地的位置，可以把检测划分为三层：模型层、执行层、输出层。需要强调的是，这三层不是三个并列的检查清单，而是同一条攻击链上的不同落点。一次提示词注入可能止步于模型层，只让模型“说错话”；也可能继续向下传导到执行层，驱动工具调用，最终造成实际的读文件、改数据、发消息。前者是输出风险，后者是行动风险，二者的处置优先级完全不同。

还需要说明本篇与第二篇的分工：MCP Server 与 Skills 的组件侧检测——来源核验、投毒识别、恶意行为扫描——已在第二篇展开，本篇不再重复。本篇关注的是这些组件被接入之后，风险如何在层级之间传导、如何被判定、以及如何回流。

3检测内容：每一层分别测什么

图 3　三层检测与攻击链传导：同一注入可能止步于输出层，也可能传导至执行层造成实际动作；判定需从模式命中推进到可利用，检测结果回写清单与台账形成闭环。

3.1　模型层：模型本身能不能被带偏

模型层检测的是模型在对抗条件下是否仍能保持预期行为。它不关心智能体调用什么工具，只关心给定输入后，模型本身会不会被诱导、被欺骗、被绕过。

表 4　模型层主要检测项

01越狱与对齐绕过

检测内容

角色扮演、前缀注入、多轮渐进、编码变换、虚拟场景嵌套等绕过手法

判定要点

单轮通过不代表安全，需覆盖变体与多轮；命中即记录完整对话与响应

02提示词注入（直接/间接）

检测内容

输入侧直接注入；网页、文档、检索结果、工具返回中的间接注入

判定要点

区分注入是否仅停留在输出层，还是进一步影响后续决策

03对抗扰动

检测内容

同音字、形近字、零宽字符、编码混淆、语义改写、语序变换

判定要点

换个说法即被绕过，说明对齐仅对特定模板有效，判定为鲁棒性不足

04幻觉与事实一致性

检测内容

忠实性、事实性、引用伪造、同一问题不同问法的一致性

判定要点

有权威依据才给确定结论；开放世界事实不作自动定论

05系统提示词泄露

检测内容

直接索取、变换诱导、结构化导出、渐进式推断

判定要点

泄露到的内容按敏感度分级，不因“只是提示词”而降级

06训练数据记忆复现

检测内容

诱导输出训练语料中的个人身份信息、密钥、内部文本

判定要点

命中即高危；需留取输出原文与诱导路径作为证据

3.2　执行层：会不会真的做错事

执行层是智能体区别于普通大模型应用的地方，也是风险量级跃升的地方。模型层出问题，最坏的结果是“说错话”；执行层出问题，结果是“做错事”——读不该读的文件、调不该调的接口、发不该发的消息。

表 5　执行层主要检测项

01指令优先级劫持

检测内容

外部内容中的指令是否覆盖系统指令；多轮渐进式诱导

判定要点

以是否驱动了非预期动作为判定依据，不以“模型口头答应”为依据

02工具越权调用

检测内容

调用范围是否超出声明权限；是否存在未声明的接口、路径与外发目标

判定要点

声明与实际不一致即判风险，不因“未造成实际损失”降级

03MCP Server 与 Skills 运行时行为

检测内容

工具定义变更后是否改变行为；是否存在先批准后篡改的形态

判定要点

一次性上线检测不足以覆盖；需运行期持续监测

04多智能体级联

检测内容

一个智能体被污染后是否影响协作链路上的其他智能体

判定要点

按级联可达范围评估影响面，不只评估首环

05持久化与资源滥用

检测内容

记忆、配置、上下文中的残留；循环调用、高频请求、成本耗尽

判定要点

结合配额与熔断策略验证，不只看单次行为是否越界

执行层检测必须与运行期监测结合，而不是只在上线前做一次。

3.3　输出层：说出来的话有没有问题

输出层检测关注模型最终产出的内容本身。这一层最容易理解，也最容易被简化成“敏感词过滤”，但实际上它至少包含五类问题：

一是敏感数据泄露，包括个人身份信息、凭证密钥、内部经营数据在输出中被直接复现；

二是违规内容，包括违法违规、违背公序良俗的生成内容；

三是日志与缓存泄露，模型输出之外的侧面通道同样可能带出敏感信息；

四是过度拒答，正常业务语境下的正当请求被误拒，影响可用性；

五是公平性偏见，在性别、地域、年龄等维度上表现出刻板印象或差别对待。

过度拒答这一项常被漏掉。安全检测如果只统计“拦住了多少”，会激励系统越收越紧，最终拦住大量正当请求。可用性与安全性需要同时度量——只朝一个方向优化的防护，本身就是一种风险。

4判定的严谨性：从“疑似”到“定论”

模型层、执行层、输出层的检测结论并不具有同等效力。有的只是模式上的命中，有的已经在沙箱里完成了实证。如何区分二者，是检测能否真正支撑决策的关键。

实践中建议把结论分为三档：

模式命中：指用例特征匹配成功，但尚未验证实际效果；

可复现：指在相同条件下能稳定重复，路径与响应清晰；

可利用：指已在沙箱中完成实证，能明确说明攻击者能得到什么、造成什么影响。

只有第三档才能支撑“必须阻断上线”这类决策，前两档更适合作为风险线索进入复核队列。

表 6　检测结论分档与可支撑的决策

01模式命中

含义

特征匹配成功，未验证实际效果

可支撑的决策

进入复核队列，不作为阻断依据

02可复现

含义

同条件下稳定重复，路径与响应清晰

可支撑的决策

纳入整改计划，限期修复

03可利用

含义

沙箱实证完成，影响明确可度量

可支撑的决策

阻断上线 / 熔断 / 紧急摘除组件

分档之外，还有三条判定纪律需要单独强调。

四态判定。结论区分通过、未通过、未评估、不适用。

“不适用”不得默认计为通过——它可能意味着该检测项对这个智能体根本不成立（如只读智能体不存在写操作越权），记为通过会虚增合规率；“未评估”保留未知，不默认为安全。延续第二篇“保留未知而非默认为安全”的立场。

未触发不等于不存在。未覆盖的分支、需特定上下文才触发的路径、依赖外部返回才激活的行为，都不能因\"这次没测出来\"就记为安全。报告应同时声明覆盖边界。

证据必须可留取。每条结论都要附请求与响应原文、复现步骤、影响面推断——没有证据链的结论，在整改争议、监管问询、责任划分时都无法使用。

一句话概括这一节：检测报告里最危险的两个字，是把“疑似”写成“存在”。前者需要复核，后者需要处置，混用会让整个检测体系失去可信度。

5检测结果回流：检测本身也是发现手段

图 4　检测结果回流：检测既产出结论，也发现未登记资产，两者共同修正台账与清单

检测过程中常常会发现台账里没有的东西——未登记的模型调用地址、未纳管的 MCP Server、清单外的外部服务调用。这些同样是资产，应当回流进第一篇建立的发现流程、进入待确认队列，而不是只作为检测结论留在报告里。

回流不只是补台账，还应完成三件事：风险归属——把问题定位到具体组件、智能体与责任人；触发复测——整改后按原路径复测，确认问题消失而非被掩盖；驱动退出——对反复整改不达标、或风险不可接受且无替代方案的对象，走下线流程。

至此闭环才算完整：发现产生台账，台账产生清单，清单给出靶心，检测产出结论，结论回头修正台账与清单。每跑一轮，下一轮的靶心就更准一些。

6小结

AI 供应链治理是一条清晰的链：先求全地发现，把所有智能体纳入视野；再求深地建档，用 AIBOM 说清构成，并校验来源与完整性；最后求准地检测——有了台账与清单，检测才知道该测谁，测出问题才知道该归因给谁。

而“求准”这一步，差的从来不是更多用例。它依赖三件事：靶心来自清单而非拍脑袋，结论分档而非一概而论，结果回流而非止于报告。做到这三件事，检测才不再是一次性的技术动作，而是治理闭环中可持续运转的一环。