智能体(Agent)上线前安全检查研究报告:从「内容安全」到「行为安全」的范式迁移

摘要

AI Agent 正在以远超安全治理能力的速度进入企业生产系统。与仅生成文本的聊天机器人不同，Agent 能够规划、调用工具、读写数据库、执行代码并自主完成多步任务——这意味着一次成功的安全缺陷，其后果不再是「一句错误的话」，而是「一个已执行的错误动作」。本报告聚焦一个具体且紧迫的工程问题：在 Agent 正式上线之前，安全团队究竟应当检查什么、按什么顺序检查、以什么作为通过标准？

报告以 OWASP 于 2025 年 12 月发布的《Agentic Applications Top 10》（ASI01–ASI10）为风险框架主干，结合 OWASP MCP Top 10、NIST AI RMF 与 AI 600-1、ISO/IEC 42001、EU AI Act 以及中国生成式 AI 服务备案与安全测评要求，构建了一套可执行的上线前检查方法论。全文的核心结论可以概括为三句话：

① 信任边界必须前移安全不能寄托于模型「理解并拒绝」恶意指令。EchoLeak（CVE-2025-32711）已证明，攻击者可以绕过专门为拦截提示注入而设计的 XPIA 分类器，实现零点击数据外泄。真正的控制点必须落在代码层面——工具调用前的确定性规则、凭证的作用域、沙箱的隔离强度。

② 检测型防御存在系统性上限公开基准显示，输入分类器可将静态注入攻击成功率从 47% 压到 1% 以下；但在自适应优化攻击下，包括轨迹级监控、双层监控在内的一批已发表防御，攻击成功率普遍回升至 78%–92%。只有「设计型防御」（能力约束、信息流标签）能保持数量级的优势。

③ 上线门禁必须证据化 NIST AI RMF 的实践教训是：把框架翻译成文档与勾选项，会产出「关于现实的声明」而非「关于现实的测量」。上线门禁要求的是可复核证据（Evidence）——一条真实的工具调用日志、一次真实被阻断的攻击、一次真实完成的回滚，而不是一次自评通过。

关键实证指标	数值	来源
EchoLeak 漏洞严重度	CVSS 9.3（首个真实世界零点击提示注入）	CVE-2025-32711 / NVD
MCP 生态公开漏洞数量	2026 年 1–4 月 40+ 枚，约每 4 天 1 枚	公开 CVE 统计
MCP 服务器存在安全问题比例	扫描 1,808 个，66% 存在安全问题	AgentSeal 扫描
官方 MCP 参考实现无认证比例	41%	AgentMarketCap 分析
静态注入无防御攻击成功率	46.5%	AgentDojo Banking 套件
自适应攻击下检测型防御 ASR	78%–92%（12 项已发表防御 >90%）	Nasr et al., The Attacker Moves Second
10 个 MCP 插件栈被利用概率	92%	VentureBeat 分析
组织报告存在危险 Agent 行为比例	80%	AIUC-1 / Stanford Trustworthy AI Lab

报告的核心立场

Agent 不是聊天机器人，而是「拥有 API 权限的数字员工」。它需要与特权员工同等的对待：身份控制、最小权限、持续监控，以及一份在它被操纵时能立刻执行的应急预案。无论框架如何演进，这四项基础工作缺一不可。

第 1 章研究背景：Agent 正在成为企业基础设施

1.1能力跃迁带来的安全范式变化

过去三年，企业 AI 的形态经历了三个清晰阶段。第一阶段是生成式助手——模型只在对话框里产出文本，安全边界等同于内容安全。第二阶段是工具调用智能体——模型开始调用 API、读写文件、执行 SQL，安全边界骤然扩张到整个业务系统。第三阶段是多智能体协同——Agent 之间互相委派任务、共享记忆，单点缺陷可以在工作流中逐级放大。

图 1AI 系统能力演进与威胁面扩张：能力每上一个台阶，安全控制点就从「模型输出」迁移到「系统动作」

这个演进的本质，是模型从「建议者」变成了「执行者」。OWASP 对这一变化的表述十分精炼：LLM Top 10 治理的是「模型说了什么」，Agentic Top 10 治理的是「系统做了什么」。两者的差异体现在四个维度上：

表 1-1LLM Top 10 与 Agentic Top 10 的治理对象差异

对比维度	LLM Top 10（2026）	Agentic Top 10（2026）
风险单元	单次模型响应	带记忆与工具的跨步骤工作流
爆炸半径	输出被人工或应用消费	动作直接作用于生产系统
时间跨度	受限于单次会话	通过持久化记忆与长期凭证延续
主要控制手段	输入验证、输出处理、数据治理	身份、最小权限、工具授权、遏制
检测面	提示词与响应日志	Agent 轨迹、工具调用、代理间消息

1.2为什么「上线前」是关键窗口期

Agent 的安全缺陷具有一个区别于传统软件的显著特征：修复成本随部署深度非线性上升。一个未加约束的工具权限，在测试环境里只是一行配置；一旦上线并接入生产数据库，它就变成了一个随时可被提示注入触发的数据外泄通道。更棘手的是，Agent 的记忆与上下文会持续累积——投毒一旦写入，影响会跨会话持久存在，事后清理成本极高。

从监管节奏看，窗口期同样在收窄。中国方面，国家网信办持续推进生成式 AI 服务备案与登记，截至 2026 年 8 月 31 日累计 1,112 款服务完成备案、731 款应用完成登记；欧盟方面，EU AI Act 的高风险合规期经《Digital Omnibus on AI》调整后，Annex III 独立高风险系统的主义务截止日推迟至 2027 年 12 月 2 日，但透明度义务（Article 50）与 GPAI 处罚机制仍在 2026 年 8 月 2 日如期生效。这意味着「先上线、后合规」的路径正在系统性失效。

为什么这份报告聚焦「上线前」而非「运行时」

运行时防护（实时护栏、行为监控）当然重要，但它解决的是「已知威胁的持续对抗」；上线前检查解决的是「结构性缺陷的一次性消除」。权限过大、凭证长期有效、缺少沙箱、没有回滚预案——这些问题的共同点是：一旦上线，修复它们需要停机改造；而如果在上线前发现，通常只是一次配置变更。把资源投在正确的时点是安全工程的基本功。

1.3报告的方法论与结构

本报告采用「框架对齐 + 实证校准 + 工程落地」的三层方法论：

框架对齐	以 OWASP Agentic Top 10（ASI01–ASI10）为风险主干，横向映射 OWASP MCP Top 10、NIST AI RMF / AI 600-1、ISO/IEC 42001、EU AI Act、MITRE ATLAS 与中国备案安全要求，确保检查项不遗漏主流合规基线。
实证校准	所有风险等级与防御有效性判断，均以公开披露的 CVE、真实事故案例与可复现的基准测试（AgentDojo、InjecAgent 等）作为依据，避免纸上推演。对不可溯源的数据做虚化处理并明确标注。
工程落地	输出可直接执行的门禁流程（Gate 0–Gate 5）、检查清单与证据要求，并配套 90 天实施路线图与成本收益量化模型。

第 2 章威胁模型：OWASP Agentic AI Top 10 深度解读

2.1框架的权威性与方法论基础

OWASP Agentic Security Initiative 于 2025 年 12 月 9 日正式发布《OWASP Top 10 for Agentic Applications 2026》，条目编号 ASI01–ASI10。这是业界首个专门面向自主式 AI Agent 的标准分类体系，由超过 100 位贡献者参与、并经 NIST、Cisco、Microsoft、AWS 等机构的评审委员会审议。它并非替代 LLM Top 10，而是对其进行扩展——每个 ASI 条目都交叉引用对应的 LLM 条目。

值得关注的是其排序方法的变化。2026 版首次将社区投票权重设为 75%、真实事故数据权重设为 25%，数据来源于 7,714 起 LLM 相关安全事件（其中 6,639 起具备足够细节可供分类）。这一方法调整带来了两个有信息量的结果：提示注入虽然在事故数据上并不突出，但被从业者投票推至首位——OWASP 将其归因于「防御效应」，即多年缓解措施压制了成功利用，而非攻击面缩小；而「过度代理」（Excessive Agency）从第 6 位跃升至第 3 位，投票与事故数据高度一致，反映出当模型获得工具与权限后，失败形态已从「坏答案」转变为「坏动作」。

一个实用的判定规则：

适用范围判定规则

如果系统只生成内容，LLM Top 10 足够；一旦系统能够调用工具、写入系统或把工作委派给另一个 Agent，则 LLM Top 10 与 Agentic Top 10 同时适用。

2.2十大风险分类详解

下表完整列出 ASI01–ASI10 的定义、典型攻击路径与对应的控制方向。

表 2-1OWASP Agentic AI Top 10（ASI01–ASI10）风险分类与攻击路径

编号	风险名称	核心机制	典型攻击路径	控制方向
ASI01	智能体目标劫持	攻击者通过直接或间接提示注入、投毒内容、恶意文档改写 Agent 目标或决策逻辑，外部表现正常但实际服务于攻击者意图。	一封无需打开的邮件 / 一份带隐藏文本的 PDF / 一个被污染的 RAG 文档，在 Agent 检索时被当作指令执行。	输入与指令严格隔离；JSON Schema 结构化；指令层级固化。
ASI02	工具滥用与利用	Agent 因提示操纵、目标劫持或不当委派，以破坏性参数调用合法工具，或以非预期顺序串联工具。	带写入权限的工具被用于篡改生产数据；shell 工具执行未校验命令。	最小权限；工具调用前置规则引擎；高风险动作人工确认。
ASI03	身份与权限滥用	Agent 继承人类或系统凭证（会话令牌、API Key、SSH 密钥、委派权限），攻击者利用薄弱权限边界横向移动。	Agent 成为非人类身份的聚合点，一旦被控即获得其名下全部密钥的权限。	独立短期凭证；与用户身份解耦；作用域最小化；独立轮换。
ASI04	智能体供应链漏洞	运行时动态获取的恶意或被入侵的工具、MCP Server、提示模板、模型文件、Agent 人格，改变 Agent 行为或泄露数据。	MCP Server 在运行时才被集成，无静态审查；工具描述字段暗藏指令。	组件签名验证；版本固定（Pin）；按包哈希而非版本号锁定。
ASI05	非预期代码执行	Agent 生成或执行代码（工作流自动化、脚本、数据处理）时，因构造提示或被污染输入而运行攻击者控制的逻辑。	自然语言路径成为新 RCE 通道；沙箱逃逸；eval 风格 API 滥用。	代码沙箱；输出执行前校验；禁止对生产系统写操作。
ASI06	记忆与上下文投毒	对 Agent 记忆、RAG 存储、向量库或上下文知识的持久化污染，影响跨会话延续，逐步改变行为或长期泄露机密。	一次投毒交互即可持久留存；Agent 会为被植入的错误信念辩护。	记忆完整性校验；上下文定期过期与刷新；行为漂移监控。
ASI07	代理间通信不安全	Agent 间（A2A）通信缺少强认证、加密或 Schema 校验，导致伪造、重放、协议降级与中间人攻击，误导整条多智能体工作流。	攻击者伪造其中一个 Agent 的身份，向执行 Agent 注入指令。	代理间消息强认证与加密；按 API-to-API 标准对待 A2A 通信。
ASI08	级联失效	单点故障（被投毒的记忆、错误的计划、被控的工具）在多智能体工作流中传播并在规模上放大为系统性事故。	一个 Agent 的幻觉成为下一个 Agent 的输入，误差在流水线中复利放大。	Agent 间熔断器；关键输出独立校验；回滚能力。
ASI09	人机信任利用	用户对 Agent 的流畅表达、表面专业性与说服力产生过度信任，使人被操纵去批准恶意命令、提供敏感数据或执行有害操作。	分析师对 Agent 的「已放行」结论橡皮图章式批准；审批点被 Agent 控制所见信息。	AI 生成内容标识；关键决策独立验证；审批点信息完整呈现。
ASI10	失控智能体	被入侵或目标偏移的 Agent 表面合规、实则追求隐藏目标，可能跨会话持续、自我重复或冒充其他 Agent，检测极为困难。	通常是 ASI01 或 ASI06 攻击成功后的终态表现。	行为基线监控；异常轨迹检测；有效的终止开关（Kill Switch）。

2.3风险优先级矩阵：先管哪几个？

十个风险并非同等紧迫。为了给上线门禁排定优先级，本报告以「业务影响严重度」与「可利用性」两个维度对 ASI01–ASI10 进行定位。需要说明的是，以下坐标为企业级通用基线判断，用于表达相对关系与分组，不构成精确的绝对评分；实际项目中应结合自身业务场景重新标定。

图 2风险矩阵：右上「优先处置区」的三类风险（ASI01 目标劫持、ASI02 工具滥用、ASI05 代码执行）均位于模型推理与系统动作的边界处，是安全控制必须附着的点位

矩阵揭示了一个对架构设计极具指导意义的结论：风险最高的三类（ASI01、ASI02、ASI05），共同点是都发生在「模型决策」与「系统执行」的交界处。Agent 决定要做某件事，系统允许或阻止它——无论防御者想施加什么控制，都必须附着在这个边界上。反过来，ASI10（失控智能体）虽然严重度极高，但它的可利用性相对较低，因为它通常是 ASI01 或 ASI06 攻击成功的终态，属于「结果」而非「入口」，其治理更依赖运行时的行为监控而非上线前的静态检查。

对上线门禁的直接启示

上线前的检查资源应优先投向「边界处」的三类风险：目标劫持（ASI01）、工具滥用（ASI02）、非预期代码执行（ASI05）。它们对应三个非常具体的工程检查项——输入与指令是否隔离、工具权限是否最小、代码执行是否沙箱化。这三项做扎实，能覆盖绝大多数高影响攻击路径。

2.4从威胁到控制：风险与框架的映射

为便于企业将检查项对齐既有合规体系，下图给出 ASI01–ASI10 与八大主流控制框架的关联矩阵。

图 3Agentic AI 风险 × 控制框架映射矩阵：实心圆表示强关联，空心圆表示弱关联；最右列为上线前红队测试用例对该风险的覆盖比例（示例基线值，需按企业实际收敛）

映射矩阵的实用价值在于「一次检查、多处合规」。例如针对 ASI04（智能体供应链）的控制——组件签名验证、版本固定、来源审查——同时满足 OWASP MCP Top 10 的 MCP04（软件供应链攻击）、ISO/IEC 42001 的 AI 系统供应链管理要求，以及 EU AI Act 对高风险系统技术文档的组件描述要求。企业不必为每套框架单独建流程，而应建立统一的控制基线，再按框架做映射声明。

第 3 章实证数据：真实事故与 CVE 证据链

3.1为什么必须用真实事故校准风险判断

安全领域最常见的失败模式，是用理论推演替代实证校准。OWASP Agentic Top 10 之所以值得作为方法论主干，一个重要原因是它的每个风险类别都能对应到公开披露的真实案例。本章梳理四起具有里程碑意义的事故——它们的共同价值在于：证明了这些攻击不是学术推演，而是可复现、已发生、且对传统防御完全透明。

3.2EchoLeak：首个生产环境零点击提示注入（CVE-2025-32711）

这是整个 Agent 安全领域最具标志性的案例，值得逐层拆解。

CVE 编号	CVE-2025-32711
漏洞代号	EchoLeak（由 Aim Security / Aim Labs 发现并披露）
受影响系统	Microsoft 365 Copilot（覆盖 Word、Excel、PowerPoint、Outlook、Teams）
严重度	CVSS 9.3（研究机构口径）；NIST NVD 另行给出 7.5，评分口径存在分歧
披露时间	2025 年 6 月 11 日（Microsoft 已服务端修复，客户无需操作）
影响范围	Copilot 权限范围内的全部数据：聊天记录、OneDrive 文件、SharePoint 内容、Teams 消息

攻击链拆解：四个「看似合理」的防御被依次穿透

EchoLeak 的技术价值，不在于某个新颖漏洞，而在于它演示了多层防御的串联失效。攻击者并没有攻破任何单一防线，而是让四道各自看起来合理的防线串成了一条通路：

表 3-1EchoLeak 攻击链中的四层防御穿透

序号	被穿越的防线	绕过方式	设计意图	为何失效
1	XPIA 跨提示注入分类器	通过特定措辞技巧规避分类器识别	专门用于检测提示注入尝试	分类器是概率性检测，面对特定构造的文本存在盲区
2	链接重定向保护	使用 reference-style Markdown 格式改写链接	阻止 Copilot 输出外部链接	过滤规则针对常见链接格式，格式变体可绕过
3	自动抓取图片机制	利用响应中的自动加载图片触发外发请求	提升回答的直观性	该机制假设被抓取内容是「被动的」，未考虑其作为数据外传通道
4	内容安全策略（CSP）	滥用 CSP 白名单内的 Microsoft Teams 代理域	限制可访问的外部域	白名单中的域本身即是被信任的出网通道

零点击意味着什么

传统提示注入攻击与钓鱼攻击一样，依赖受害者「做点什么」——打开可疑文档、粘贴不可信文本、点击链接、批准动作。这个依赖同时也是防御者的主要控制面：用户培训、可疑链接告警、附件沙箱、以及最基本的用户怀疑，都建立在这个假设之上。

EchoLeak 彻底移除了这个假设。受害者不需要打开邮件、不需要点击链接、不需要批准任何操作。攻击载荷只是静静地躺在一个邮箱里，等待 Copilot 自己的后台检索流程在处理一次无关的用户提问时，把它作为上下文拉进模型。从安全工程的角度看，这个缺陷的形态更接近传统的零点击远程漏洞利用，而非社会工程攻击——尽管其载荷机制是提示注入而非内存破坏。

EchoLeak 的三条工程启示

第一，输入侧防御（过滤进入模型的内容）的投入产出比，低于输出侧与架构侧防御（限制模型能做什么）。第二，当 LLM 位于拥有广泛内部数据访问权限的流水线中心时，流水线的整体风险是各层防御的乘积而非加和——任何一层失效，被有能力的攻击者串联后即足以致命。第三，「被信任的内部域」本身就是出网通道，CSP 白名单需要按最小必要原则收敛。

3.3其他关键事故：从 Copilot Studio 到 GitHub MCP

表 3-22025–2026 年 Agent 安全关键事故一览

时间	事件	类型	关键事实	对应风险
2025-06	Microsoft 365 Copilot EchoLeak	零点击提示注入 → 数据外泄	CVSS 9.3；绕过 XPIA 分类器；单封邮件实现企业数据外泄。	ASI01 / ASI02
2025-06	Asana MCP Server 跨租户访问	跨租户数据暴露	访问控制逻辑缺陷，导致一个租户的 AI Agent 可访问其他租户的项目数据。SaaS 环境中最基础的隔离边界被打破。	ASI02 / ASI04
2025	Supabase Cursor Agent 被劫持	SQL 注入 → 权限滥用	攻击者将 SQL 指令嵌入客服工单文本，具备 service-role 高权限的 Agent 将其当作命令执行，外泄集成令牌。	ASI01 / ASI02
2025-05	GitHub MCP Server 提示注入	间接提示注入 → 代码外泄	恶意公开 Issue 中嵌入指令，使用 GitHub MCP 的 AI 助手在抓取该 Issue 时将其作为上下文处理，把私有仓库代码、财务数据外泄至公开 PR。	ASI01 / ASI02
2025-08	Claude Code / Copilot Studio AIjacking	AI 劫持 → 完整数据外泄	Zenity Labs 披露的 Copilot Studio 案例显示，AI 劫持可导向完整数据外泄链路。	ASI01 / ASI09
2025-11	Agent 框架组件供应链投毒	供应链攻击	Barracuda Security 报告识别出 43 个被植入漏洞的 Agent 框架组件。	ASI04
2025-09	Postmark MCP 假冒包	供应链木马	伪造的 Postmark MCP 包（周下载约 1,500 次）静默将外发邮件 BCC 至攻击者地址，用户侧行为表现完全正常。	ASI04
2026-04	MCP STDIO 架构缺陷（OX Security）	架构级命令执行	官方 SDK 的 STDIO 传输允许配置值直接流入命令执行；约 20 万台服务器受影响；Anthropic 将其归类为「预期行为」。	ASI05 / ASI04

3.4事故暴露的共同结构性缺陷

把上述案例横向对比，可以看到它们并非孤立的实现缺陷，而是同一个结构问题的不同表现：

缺陷一：指令与数据无法分离	Agent 天然难以区分「用户给我的指令」和「我读到的内容」。OWASP 的表述一针见血：Agent 在区分指令与数据方面的挣扎，意味着它处理的每一份不可信内容都是潜在攻击向量。
缺陷二：工具输出被赋予过高信任	工具返回的查询结果、文件内容、API 响应、错误信息，全部以同等权威进入模型上下文。协议层面没有任何机制可以让服务端标注「这是不可信数据」。
缺陷三：凭证权限远超任务所需	Agent 往往继承用户会话或使用长期有效的服务账户密钥。一旦被控，攻击者获得的不是「一次调用的权限」，而是该凭证名下的全部权限。
缺陷四：传统安全工具完全失明	恶意载荷是纯自然语言，没有签名、没有附件、没有可执行代码。防病毒、网络监控、静态扫描在整个攻击过程中都没有可检测的对象。

第 4 章供应链风险：MCP 生态与工具投毒

4.1MCP 的爆发式增长与信任模型错配

Model Context Protocol（MCP）在极短时间内成为 Agent 工具集成的事实标准。Anthropic 于 2024 年末发布时生态内约有 714 个服务器，到 2026 年初这个数字已突破 16,000 个，约 12 个月内增长 22 倍。开发者集成 MCP Server 的方式，与安装 npm 包高度相似：快速、不审计内部实现、通常也不完整阅读工具描述。

问题在于，MCP 的信任模型从一开始就是为开发者便利性设计的，而非为企业威胁模型设计的。协议允许任何已连接的 MCP Server 向模型描述自己的工具，包括在工具 description 字段中写入任意元数据。模型会读取这些元数据，而用户通常不会看。这个信息不对称正是工具投毒攻击的立足点。

表 4-1MCP 生态安全现状关键指标

生态指标	数值	含义
MCP Server 数量增长	714 → 16,000+（约 12 个月，22 倍）	生态扩张速度远超安全治理能力建设速度
存在安全问题的 MCP Server 比例	66%（扫描 1,808 个）	三分之二的服务器在部署前就存在安全问题
官方参考实现无认证比例	41%	连参考实现都缺少认证，第三方实现更难保障
使用易受路径穿越影响的文件操作	82%（基于 2,614 个实现调研）	文件类工具是主要攻击面
涉及代码注入风险的 API 使用	67%	eval/exec 类调用普遍存在
10 个 MCP 插件栈的被利用概率	92%	栈越深，至少一个组件存在缺陷的概率趋近于必然

4.2漏洞披露时间线与攻击类别分布

图 4MCP 生态公开漏洞披露时间线：2026 年 1–4 月披露节奏明显加快，约每 4 天新增 1 枚 CVE；RCE / 命令注入类占比最高

按漏洞类别统计，Shell / exec 注入占 43%，工具链基础设施缺陷占 20%，认证绕过占 13%，路径穿越占 10%，其余（SSRF、供应链）占 14%。RCE 占比最高这一事实值得警惕——它意味着漏洞的后果不是「信息泄露」，而是「在开发者或员工机器上的直接代码执行」。

表 4-2MCP 生态代表性已确认 CVE（按时间排序）

CVE 编号	CVSS	组件	漏洞类型
CVE-2025-49596	9.4	Anthropic MCP Inspector	未认证远程代码执行（调试工具自身成为攻击面）
CVE-2025-6514	9.6	mcp-remote（npm，43.7 万次下载）	经 OAuth 流程的 OS 命令注入，首个大规模影响的 MCP RCE
CVE-2025-54136	8.8	Cursor IDE MCP（MCPoison）	工具描述符注入；信任决策缓存后不再复验
CVE-2025-54135	9.8	Cursor IDE MCP（CurXecute）	工作区文件写入 → RCE
CVE-2025-53109 / 53110	7.3	Anthropic Filesystem MCP	符号链接 / 路径前缀绕过，实现沙箱逃逸
CVE-2025-59528	10.0	Flowise CustomMCP 节点	STDIO 传输 → RCE（CVSS 满分）
CVE-2025-53967	8.0	Framelink Figma MCP	未净化的 curl 回退导致命令注入
CVE-2025-68143/44/45	9.1	Anthropic mcp-server-git	三个链式缺陷，可经恶意 .git/config 实现 RCE
CVE-2026-0755	9.8	gemini-mcp-tool	经 execAsync 的命令注入
CVE-2025-65513	9.3	Fetch MCP Server	私网 IP 校验绕过导致 SSRF
CVE-2026-33032	9.8	nginx-ui MCP endpoint	认证绕过 → RCE
CVE-2026-23744	9.8	MCPJam Inspector	监听 0.0.0.0 的未认证 RCE

4.3五大攻击模式：比记住 CVE 更重要的是理解模式

分析完整 CVE 数据集后可以发现，真正有复用价值的是攻击模式的归纳，而非逐个 CVE 的记忆。

表 4-3MCP 生态五大攻击模式归纳

模式	机理	为何有效	真实案例
模式 1工具投毒	向 MCP 工具的描述或元数据中注入恶意指令，Agent 读取后当作合法指令执行。	Agent 将工具描述视为可信输入；没有标准机制去验证或签名工具描述。控制工具描述即控制 Agent 行为。	2025-04 WhatsApp MCP 攻击：通过工具描述投毒，使合法 WhatsApp Server 将数百条消息转发至攻击者号码，无需任何代码执行。
模式 2信任缓存的 Rug Pull	先提交看似正常的配置获取审批，再在后续更新中注入恶意逻辑，改动静默生效。	MCP 客户端在用户批准后通常不再重新验证配置，信任决策被永久固化。	CVE-2025-54136（MCPoison）：影响所有缓存信任决策而不定期复验的 MCP 客户端。
模式 3STDIO 命令执行	通过 STDIO 传输启动 MCP Server 时执行 OS 命令，缺乏执行前校验；配置值可直接流入命令执行。	协议假设该命令代表合法服务器二进制，且该架构是默认接口，被所有实现继承。	2026-04 OX Security 披露：约 20 万台服务器受影响；Anthropic 归类为「预期行为」，将净化责任交予开发者。
模式 4路径穿越与沙箱逃逸	利用符号链接、路径前缀匹配缺陷绕过目录限制，读写沙箱外的任意文件。	路径校验逻辑的实现细节容易出错，且校验点与真实文件系统语义之间存在间隙。	CVE-2025-53109/53110（EscapeRoute）：官方 Filesystem MCP 的目录限制被绕过。
模式 5注册表供应链投毒	向 MCP 注册表上传假冒包，功能表面正常，后台静默外泄 API Key 与环境变量。	MCP 注册表对提交内容缺乏充分审核；开发者按名称信任包。	2025-09 Postmark 假冒 MCP Server；2025-10 Smithery 路径穿越导致 3,000+ 托管 MCP Server 被波及。

供应链治理的三条硬规则

第一，MCP Server 的审批必须作为安全控制而非配置步骤——任何不在批准清单中的 Server 都应在主机层面阻断。第二，按包哈希而非版本号固定已批准 Server，以检测 Rug Pull 型攻击。第三，工具描述必须与代码同等对待：在连接任何 Server 之前，审查完整的 JSON Schema，而不仅是显示名称与简要说明。

第 5 章护栏的真实边界：检测型防御为何失效

5.1一个被广泛误读的数字

许多厂商在介绍 Agent 安全护栏时，会引用「攻击成功率从 46.5% 降至 0.7%」这类数字。这个数字本身是真实的——它来自 AgentDojo Banking 套件的实测——但它的解释范围远小于宣传口径。

该测试使用的是 important_instructions 这一单一固定模板，在全部 144 个（用户任务 × 注入任务）用例中重复。因此 0.7% 的实际含义是：该护栏能够识别这个特定模板，而非能够阻止智能体注入。用一个模板去测量一个防御，得到的只是该防御的上界——正如用静态语料库测量检测器，得到的是检测器的上界。这个测试没有度量「会适应的攻击者」。

5.2静态攻击 vs 自适应攻击：数量级的差距

图 5(a) 静态注入攻击下输入分类器可将 ASR 从 46.5% 降至 12%；(b) 但同一批检测型防御在自适应优化攻击下 ASR 回升至 78%–92%，只有设计型防御保持数量级优势

上图 (b) 所依据的数据来自一项关键的对抗性研究：Nasr 等人的《The Attacker Moves Second》测试了 12 项已发表的防御方案，结果显示在自适应攻击下它们的攻击成功率普遍超过 90%。更具冲击力的细节是：结构复杂度并不带来安全性提升。双层监控（PromptGuard 2 + AlignmentCheck）在 GCG 优化攻击下 ASR 达到 90%，而针对 Extract-and-Evaluate 监控器的攻击 ASR 甚至达到 95.5%——其中很大一部分原因是成功操纵了裁判模型的评分机制。

反直觉的结论

增加监控层数会扩大攻击面。研究明确指出：监控协议的结构复杂度并不增强安全性；自适应攻击者恰恰会利用那些为保护而设计的机制。这是「纵深防御」在 Agent 场景下的重要修正——层层叠加同类防御（都是检测型）并不产生纵深，只是增加了可被利用的组件。

5.3三类防御的本质差异

理解这个问题的关键，是把防御按机理分为三类，而不是按部署位置分类。

表 5-1检测型 / 行为型 / 设计型防御的机理与有效性对比（数据为公开研究所报数量级，非精确可比）

防御族	机理	代表方案	静态攻击 ASR	自适应攻击 ASR	本质局限
检测型	识别输入中的攻击并拒绝，依赖分类器、困惑度阈值或二次模型。	输入分类器、PromptGuard、轨迹级监控	10%–12%	78%–92%	安全性取决于「能否正确分类攻击」；攻击者一旦能优化输入，分类即失效。
行为型	通过微调让模型本身更难被劫持，如指令/数据通道分离训练。	StruQ、SecAlign	<2%	<15%（优化型）	通道分离是「学习到的行为」而非「强制的不可变性」，足够强的优化器仍能穿透，构成残余风险。
设计型	改变架构，使不可信内容在结构上无法触发有后果的动作，无论是否被识别为攻击。	双 LLM 模式、CaMeL、FIDES、Progent	≈1%	≈15%	代价是效用损失与工程复杂度；需要重新设计 Agent 的规划与执行结构。

需要强调一个测量方法论上的警告：不同基准套件之间攻击成功率不可直接比较。InjecAgent 与 AgentDojo 使用不同的任务分布、不同的攻击者武器库、不同的成功定义，即便数值接近也不意味着度量的是同一件事。本报告引用这些数字，是取其数量级与方向——无防御的 Agent 有两位数比例被劫持、廉价防御能将其降低数倍、设计型防御可将违规子集压向零，而不应把几个百分点的小差距当作显著结论。

5.42026 年公开红队竞赛数据

2026 年 AgentDojo 相关工作组织了一次公开红队竞赛，为「当前前沿模型在真实对抗下有多脆弱」提供了规模化证据：

表 5-22026 年公开 Agent 红队竞赛关键结果

指标	数值	解读
参与人数	464 人	覆盖学术界与工业界的广泛参与者
提交攻击次数	272,000 次	攻击尝试规模达到统计显著水平
成功攻击次数	8,648 次	在受控环境中被确认成功的攻击
覆盖场景数	41 个	涵盖工具调用、编码、计算机操作类 Agent
评测的前沿模型数	13 个	包括多家主流厂商的旗舰模型
模型攻击成功率区间	0.5% – 8.5%	所有评测模型均存在脆弱性，无一例外

这组数据的核心启示是：能力提升并不自动带来提示注入鲁棒性。0.5%–8.5% 的区间看起来不高，但要注意这是在「已知的目标环境、有限的时间窗口、公开的评测条件」下取得的。在真实攻击场景中，攻击者有无限时间、有具体的业务动机、并且会针对特定部署做适配。这个数字应当被理解为「下限」，而非「风险水平」。

对上线门禁的方法论要求

第一，护栏的有效性必须用自适应攻击来测量，用静态模板测出的数字不能作为上线依据。第二，任何安全控制都应回答「当攻击者知道我在用这个控制时，它是否还有效」。第三，不要把安全论证建立在「正确分类攻击」的能力上——应优先投注于「即使没识别出攻击也无法造成后果」的设计型控制。

第 6 章监管与合规基线：中国、欧盟与美国三线要求

6.1中国：备案、登记与安全测评

中国的生成式 AI 治理以《生成式人工智能服务管理暂行办法》为核心，形成了算法备案、大模型备案、AI 应用登记三条路径并行的框架。对于通过 API 或其他方式直接调用已备案模型能力的应用或功能，由地方网信办开展登记。

表 6-1中国生成式 AI 服务备案与登记进度

时点	累计备案服务数	累计登记应用数	说明
2026-02 底	796 款	—	全国累计（国家网信办公告口径）
2026-06-30	988 款	598 款	5–6 月新增备案 120 款、登记 68 款
2026-08-31	1,112 款	731 款	7–8 月新增备案 124 款（含 7 款端侧服务）、登记 133 款

对已上线的生成式 AI 应用或功能，监管要求其在显著位置或产品详情页面公示所使用的已备案或已登记生成式 AI 服务情况，注明模型名称、备案号或上线编号。这一点对 Agent 类产品尤其重要——Agent 往往同时调用多个模型与外部工具，其公示范围与责任边界需要在设计阶段就明确。

6.2欧盟：EU AI Act 的时点变化与不变项

EU AI Act 自 2024 年 8 月生效，但其义务分阶段适用。2026 年的关键变化是《Digital Omnibus on AI》对高风险合规时限的推迟——该提案由欧盟委员会于 2025 年 11 月 19 日提出，欧洲议会于 2026 年 6 月 16 日以 423 票对 57 票通过，理事会于 6 月 29 日完成终审，确立了新的两个固定时点。

表 6-2EU AI Act 关键合规时点（含 Digital Omnibus 调整后）

时点	适用对象	义务内容	是否受 Omnibus 影响
2025-02-02	全部提供者	禁止性实践（Prohibited Practices）生效	否，保持原状
2025-08-02	GPAI 模型提供者	GPAI 义务开始适用；委员会执法工具就位	否，保持原状
2026-08-02	对话类 / 生成内容类产品	Article 50 透明度义务：聊天机器人披露、AI 生成内容标注、深伪标识；GPAI 完整处罚机制生效	否，如期生效
2027-12-02	Annex III 独立高风险系统	完整合规：合格评定、技术文档、风险管理、数据治理、人工监督、CE 标识、欧盟数据库注册	是，由 2026-08-02 推迟至此
2028-08-02	Annex I 嵌入式高风险系统	嵌入受其他产品安全法规约束产品中的 AI 组件（医疗器械、机械等）	是，由 2027-08-02 推迟至此

「我们还有时间」是一种危险的误读

推迟的是 Annex III 高风险系统的合格评定机制，而非透明度层。如果产品是面向欧盟用户的对话式助手或生成 AI 内容，Article 50 的披露义务在 2026 年 8 月 2 日并未推迟。更实际的压力来自供给侧：公告机构的产能是有限的，所有等待原定 2026 年 8 月截止日期的企业，加上所有转向 2027 年 12 月的企业，都在竞争同一批合格评定机构——更长的时限不等于更短的排队。

6.3美国：NIST 的框架与 AI Agent 标准倡议

NIST 的路线值得单独说明，因为它揭示了标准体系与部署现实之间的落差。目前可用的基线包括：

NIST AI RMF 1.0	2023 年发布的框架，四个功能：Govern（治理，贯穿性）、Map（建立上下文）、Measure（测量）、Manage（处置）。需注意 NIST 明确 Govern 与其他三者性质不同，是贯穿全部风险管理过程的横向职能。框架官方页面显示其「正在修订」，但截至目前 AI RMF 2.0 尚未发布，1.0 仍是实际工作版本。
NIST AI 600-1	2024 年 7 月发布的生成式 AI Profile，将 GenAI 特有风险（捏造、数据隐私、有害偏见、知识产权暴露等）映射到上述四个功能。
COSAiS 项目	将长期使用的 SP 800-53 安全控制翻译为 AI 用例控制叠加层，规划的叠加层包括：使用生成式 AI 助手、使用与微调预测式 AI、面向 AI 开发者的安全控制，以及「使用 AI Agent 系统」（含单 Agent 与多 Agent）。
NIST IR 8596（草案）	Cyber AI Profile，2025 年 12 月草案，把 AI 纳入网络安全框架，覆盖 AI 系统自身安全、AI 赋能攻击、AI 赋能防御三个方向。
AI Agent Standards Initiative	2026 年 2 月由 NIST 人工智能标准与创新中心启动，聚焦互操作性、AI Agent 安全与 Agent 身份。

从这份清单可以读出两个重要判断。其一，重心已经明确转移到 AI Agent，这正是绝大多数组织当前部署的形态。其二，也是更值得深思的一点：面向 Agent 的控制叠加层尚未起草完成。标准机构明显落后于部署曲线——你的 Agent 已经在运行，而为其编写的控制集还没有定稿。

6.4NIST AI Agent 身份与授权模型参考

尽管控制叠加层尚未定稿，NIST 在 AI Agent Standards Initiative 中已提出一个对企业落地很有参考价值的身份与授权框架，包含四个要素：

表 6-3NIST AI Agent 身份与授权框架四要素

要素	内容	工程含义
Agent ID	每个 Agent 实例的唯一、防篡改标识符	像云环境的服务账户一样，Agent 必须可被唯一识别，不能匿名运行
能力声明	机器可读的能力清单（capability declaration），逐工具声明访问级别、数据分类、是否需审批	能力声明同时是文档与强制执行依据；运行时系统应据此校验 Agent 动作，拒绝超出声明范围的行为
授权范围	对 Agent 可执行动作的显式边界	明确记录授权人、授权时间、过期时间、作用域与限制条件
委派链	谁在什么条件下授权了该 Agent 的可追溯记录	解决归因问题：任何 Agent 动作都应能回溯到具体的授权来源

NIST 同时提出了与决策风险等级挂钩的解释层级要求，对企业设计审批流程有直接指导意义：常规决策记录动作与触发输入；有后果的决策记录推理链、考虑过的替代方案与置信度；高影响决策需提供完整推理轨迹并支持人工复核。这一分级思想可以直接转化为 Agent 工具调用的日志与审计要求。

6.5三线合规要求的收敛点

把中、欧、美三线的要求并列观察，会发现它们在方法论上高度收敛于四个共同点，这为企业建立统一的控制基线提供了依据：

表 6-4三线合规要求的收敛点对照

收敛点	中国要求	欧盟要求	美国（NIST）要求
资产可见性	备案与登记需明确模型名称、备案号	Annex III 系统须在欧盟数据库注册	AI Agent 清单与能力声明
风险分级处置	按舆论属性 / 社会动员能力区分路径	按 Annex I / III 与禁止类分级	按决策风险等级设定解释层级
人工监督与可解释	内容审核与安全管理制度	Article 26 部署者义务；人工监督	Agent 授权范围与委派链
记录与追溯	备案信息公示与更新	Article 12 自动日志记录义务	加密审计日志；记录全部工具调用

建立统一控制基线，而非三套流程

三线要求在「可见、分级、可监督、可追溯」四个维度上高度一致。企业应建立一套统一的 Agent 安全控制基线，再针对各法域做映射声明与差异补充，而不是维护三套并行流程。这既能降低合规成本，也能避免因流程割裂导致的实际控制盲区。

第 7 章核心方法论：上线前安全检查六道门禁

7.1设计原则

本章提出本报告的核心方法论——一套可执行、可审计、可证据化的上线前检查流程。其设计遵循四条原则：

原则一：Fail-Closed	任一环节不通过即阻断发布，不存在「风险已知悉、批准放行」的例外通道。例外只能通过正式的、有责任人签字的风险接受流程处理，且必须记录在案。
原则二：证据优于声明	每个门禁的通过标准是可复核的证据（Evidence）——一条真实的工具调用日志、一次真实被阻断的攻击、一次真实完成的回滚演练，而不是一份自评清单。这是 NIST AI RMF 实践中最重要的教训。
原则三：独立验证	研发侧自查与安全侧验证分离。攻击测试必须由不参与开发、且不受交付进度压力影响的团队执行，否则测试强度会在项目压力下系统性衰减。
原则四：门禁前移	能在线下拦截的问题绝不带到灰度阶段。修复成本随部署深度非线性上升，这是把检查集中在「上线前」的根本理由。

图 6Agent 上线前安全检查六道门禁：从资产登记到灰度发布，形成完整的证据链闭环

7.2Gate 0：资产与身份登记

这是全部门禁的前置条件，也是最容易被跳过的一环。没有清单就无法安全——你无法保护你不知道存在的 Agent。值得注意的一个数据是：47% 的组织无法对影子 AI 建立有效管控。

表 7-1Gate 0 检查项与证据要求

检查项	检查内容	通过标准（证据要求）
Agent 台账	组织内运行的每个 Agent 的名称、版本、责任人、业务用途、部署环境	清单覆盖率 100%；每个 Agent 有唯一责任人与联系方式
能力声明	机器可读的能力清单：可调用工具、访问级别、数据分类、是否需审批	能力声明文件已生成并与运行时配置一致（非文档与实现脱节）
工具台账	全部可调用工具及其权限范围、数据可达范围	工具清单完整，每个工具标注权限级别与数据分类
Agent 身份	是否为每个 Agent 分配独立、可验证、可轮换的身份凭证	无 Agent 复用人类凭证；凭证有明确过期时间
外部依赖	全部 MCP Server、插件、第三方组件及其维护方	依赖清单含来源、维护方、版本与哈希值
数据边界	Agent 可读写的全部数据源及其敏感度分级	数据流图已完成，标注信任边界与跨边界点

为什么把「台账」放在第一道门禁

因为后续所有检查都以它为索引。安全团队要知道去测什么、要限制什么权限、要审计哪条链路，都必须先有一份准确的清单。实践中，最有效的做法是把 Agent 登记与 CI/CD 流程绑定——未登记的 Agent 无法通过部署流水线，从机制上消除「影子 Agent」。

7.3Gate 1：静态合规与供应链审查

这一道门禁的目标，是在任何动态测试之前，先把「已知不安全」的组件挡在门外。

表 7-2Gate 1 审查对象与通过标准

审查对象	审查要点	通过标准
代码与配置	提示词模板、系统指令、工具定义中是否存在硬编码凭证或危险默认值	无硬编码密钥；无生产环境宽松默认配置（如监听 0.0.0.0）
SBOM 与依赖	全部依赖项的版本、来源、已知漏洞（CVE）状态	无未修复的高危 CVE；依赖按哈希固定而非仅按版本号
MCP Server 清单	每个 Server 是否在批准清单中、是否自托管或经审计、工具描述是否审查	全部 Server 已批准；工具描述完整审查记录（含 JSON Schema）；按哈希固定
认证机制	MCP 与外部工具的认证方式	远程连接使用 OAuth 2.0；拒绝以环境变量传递的静态 API Key；采用细粒度工具作用域
网络暴露面	是否存在公网可访问的 MCP 端点或调试接口	调试端点（如 Inspector 类工具）未暴露在公网；私网地址访问受控（阻断 SSRF）
许可与数据来源	训练/检索数据来源合法性；开源组件许可合规	数据来源可追溯；许可合规；已生成数据来源说明

这一环节的一个实操要点：把工具描述当作不可信代码来审查。在连接任何 MCP Server 之前，逐字段审查其完整 JSON Schema——不是看显示名称，而是看 description 字段里是否夹带了行为指令、是否声明了超出功能所需的参数。

7.4Gate 2：对抗性红队测试

这是整条门禁链中最具技术含量、也最容易被「走过场」的环节。基于第 5 章的结论，测试设计必须满足一个硬性要求：必须包含自适应攻击，而不能只有静态模板。

表 7-3Gate 2 对抗性测试矩阵

测试类别	测试内容	最低用例要求	通过标准
间接提示注入	在 Agent 会读取的内容（邮件、文档、网页、RAG 文档、工单文本）中嵌入指令	覆盖全部外部数据源类型；每类 ≥ 10 个用例	无可导致越权动作或数据外泄的成功案例
自适应注入	针对已部署护栏做定向优化的攻击（而非固定模板）	≥ 20 个迭代优化用例	护栏 ASR 在自适应条件下仍低于设定阈值（建议 ≤ 15%）
目标劫持	诱导 Agent 偏离原始任务目标、转向攻击者意图	覆盖多步任务场景	目标偏移可被检测并在动作执行前阻断
工具滥用	以破坏性参数调用合法工具；非预期工具串联序列	覆盖全部写操作类工具	危险参数被规则引擎拦截；风险动作需人工确认
代码执行逃逸	沙箱逃逸、eval 类 API 滥用、路径穿越、符号链接绕过	≥ 15 个用例	全部逃逸尝试被阻断并产生告警
记忆投毒	污染 Agent 记忆 / 向量库，验证跨会话影响	≥ 10 个跨会话用例	投毒内容在下一次会话中被检出或无效
供应链植入	篡改工具描述、模拟 Rug Pull（先正常后恶意）	覆盖全部第三方 Server	描述变更被检测；哈希校验失败即阻断
人机信任利用	验证审批环节是否会被 Agent 的输出操纵	覆盖全部人工审批点	审批界面完整呈现动作、目标、数据源与理由，不可被 Agent 裁剪

红队测试的一个方法论警告

在 AgentDojo 的一次实测中，某防御方案在离线测试中全部 46 项测试通过，但接入真实框架后完全无效——原因是防御组件被错误地挂载在工具执行循环之后，它观察到的是「已经成功的攻击」。这个案例说明：集成测试不可被单元测试替代。红队测试必须在真实的 Agent 运行时与真实的工具集上执行，用真实的任务与权限，攻击结果必须通过环境状态检查来验证，而不是通过模型输出来判断。

7.5Gate 3：权限与围栏验证

本报告在威胁分析中反复回到一个结论：最有效的防御是设计型防御——让不可信内容在结构上无法触发有后果的动作。这对应 OWASP 提出的核心原则「最小代理权」（Least Agency）：Agent 只应被授予完成其任务所必需的最小自主性。这一原则需要落到四个层次上。

图 7最小代理权四层约束模型：从执行层的物理隔离到意图层的目标边界声明，逐层收窄爆炸半径

表 7-4最小代理权四层验证要求

层次	控制要点	验证方法（证据要求）
L4 意图层	目标边界声明、指令层级固化、不可覆盖的系统策略	尝试用外部内容覆盖系统策略，验证不可覆盖性（拒绝不可被绕过）
L3 能力层	工具白名单、参数 JSON Schema 强校验、动作前置规则引擎	以越界参数调用工具，验证被规则引擎阻断；确认规则在工具执行前生效
L2 身份层	独立短期凭证、与用户身份解耦、作用域最小化、定期轮换	核查凭证有效期与作用域；确认 Agent 不继承人类会话令牌
L1 执行层	容器 / 微虚拟机隔离、非 root 运行、网络命名空间收敛	在沙箱内尝试逃逸与横向访问，验证失败；确认无宿主文件系统可达

需要人工审批的动作清单

一个常见的落地障碍是：不知道哪些动作该设审批。以下清单可作为起点——凡涉及对外通信、资金交易、代码执行、文件删除、权限变更、记忆写入、业务记录更新的动作，均应强制人工确认。审批界面需完整呈现计划动作、目标对象、数据来源与理由四项信息，且这些信息不可被 Agent 裁剪或美化。

7.6Gate 4：观测、审计与回滚演练

OWASP 的表述值得引用：「最小代理权与可观测性是刻意配对的。没有可观测性的最小代理权是盲目的约束；没有最小代理权的可观测性只是对正在发生的伤害进行监视。」二者缺一不可。

表 7-5Gate 4 观测与回滚检查项

检查项	要求	证据
全链路审计	记录每一次工具调用、上下文变更、Agent 与用户交互；日志不可篡改	抽样验证日志完整性；确认仅追加（append-only）存储
决策可追溯	按决策风险等级记录相应的推理轨迹（常规/有后果/高影响三级）	抽取三类决策样本，验证记录粒度符合分级要求
熔断机制	速率限制、超时、预算上限、异常行为熔断器已配置并生效	实测触发熔断并记录响应时间
回滚能力	关键动作可回滚；回滚流程已有责任人并演练过	完成至少一次真实回滚演练并留存记录
终止开关	存在可立即停止 Agent 运行的有效机制（Kill Switch）	实测终止开关，测量生效延迟
告警与响应	异常行为告警可送达值班人员；有明确的 Agent 事件响应预案	完成一次桌面推演；确认告警送达链路

必须演练，不能只做配置

「我们配置了熔断」与「我们在故障时能熔断」是两件事。Agent 事故的升级速度远快于人类反应速度——因为 Agent 执行动作的速度就是机器速度。回滚演练与终止开关测试必须作为上线前的硬性门槛，而不只是运维手册里的一个章节。

7.7Gate 5：灰度发布与持续再评估

上线不是终点，而是风险观测的开始。最后一道门禁的目标是确保能力扩张与社会发布范围扩张是同步受控的。

表 7-6Gate 5 灰度发布与持续监控要求

控制项	要求
影子流量验证	Agent 先以只读 / 建议模式运行，输出不产生实际动作，与人工决策结果对比
金丝雀发布	按用户组或业务场景逐步放量，每阶段设置明确的观测指标与回滚条件
行为漂移监控	建立 Agent 行为基线（工具调用分布、动作频率、数据访问模式），持续比对偏离度
再评估触发条件	以下事件必须触发重新评估：新增工具或 MCP Server、权限范围变更、模型版本升级、发生安全事件、业务场景重大变化
定期复核	无论是否发生变更，按固定周期（建议季度）复核权限必要性与控制有效性

门禁的真正价值在于「变更时重新触发」

Agent 的安全状态不是一次性认证，而是持续属性。攻击面会随着每一次工具新增、每一次模型升级、每一次权限调整而变化。最容易出事的时间点是「上线三个月后加了一个新工具」——此时原有评估已过期，但团队默认系统仍然是安全的。把再评估条件写进流程，比任何技术控制都更能降低长期风险。

第 8 章成本收益：门禁投入与风险敞口的量化权衡

8.1投入产出结构

安全投入的论证常常陷入「合规成本」的话语框架，而不是「风险削减」的工程框架。本章尝试用可量化的方式表达门禁的价值。需要说明的是，本节中的成本与损失数值均为基于行业实践的估算区间，用于表达相对关系与量级，不构成精确测算，实际项目中应结合自身业务规模重新标定。

图 8企业 Agent 安全就绪度六维自评模型：三种典型企业画像的对比。滞后型企业的共同特征是「没有清单」，这使其无法开展任何有效的后续控制

表 8-1六道门禁的投入结构与风险后果对照

门禁环节	相对投入	主要成本构成	若缺失的典型风险后果
Gate 0 资产与身份登记	低	流程建设与台账维护，一次性投入为主	影子 Agent 不可见；后续所有控制失去索引基础
Gate 1 静态合规与供应链审查	低–中	SBOM 工具、依赖审查人力	已知高危 CVE 直接进入生产；供应链投毒无感知
Gate 2 对抗性红队测试	中–高	红队人力、测试环境、自动化攻击工具	上线后才发现结构性注入缺陷，需停机改造
Gate 3 权限与围栏验证	中	架构改造：沙箱、规则引擎、凭证体系	爆炸半径不受控；一次注入即等于一次全域越权
Gate 4 观测与回滚演练	中	日志基础设施、审计存储、演练工时	事件不可追溯；事故无法止损；监管检查无法举证
Gate 5 灰度与持续监控	中（持续性）	行为基线建模、持续监控运维	变更引入的新风险长期未被发现

8.2为什么门禁的经济性优于事后补救

这道算术的关键在于修复成本的非线性增长曲线。同一个缺陷在不同阶段被发现，处置成本可能相差一到两个数量级：

表 8-2缺陷发现阶段与处置成本的关系（相对量级示意）

发现阶段	典型处置动作	相对成本	附加损失
上线前（Gate 2/3 发现）	修改配置、收敛权限、补充规则	1×（基准）	几乎无外部损失
灰度阶段发现	暂停放量、回滚、修复后重新评估	3–5×	项目延期；部分数据可能已被访问
全量上线后发现	停机改造、凭证轮换、数据影响评估、客户通知	10–50×	数据外泄、合规处罚、客户信任受损
被外部披露 / 监管调查	应急响应、法律应对、监管沟通、公关	50×+	监管处罚、声誉损失、业务中断

把上表与表 8-1 对照，可以得到门禁投入的核心论证：在 Gate 2 或 Gate 3 拦截一个权限过大问题的成本，是把一行配置从「全权限」改为「只读」；而同样的问题如果在生产环境暴露，需要的是凭证体系重建、数据影响面评估、可能的外部通报，以及一次对客户信任的修复。这正是「上线前」作为关键窗口期的经济含义。

8.3与监管成本的对照

监管处罚为上述论证提供了外部锚点。EU AI Act 对违反高风险义务的处罚上限为3,500 万欧元或全球年营业额的 7%（取较高者），这一量级显著高于绝大多数企业的 Agent 安全建设总投入。中国方面，国家网信办第一阶段执法累计处置违规 AI 产品 3,500 余款，各地监管部门针对算法备案更新不及时、未履行登记程序等问题的处罚持续增加——其中相当一部分属于流程性合规缺失，正是 Gate 0 与 Gate 1 能够直接覆盖的范围。

给决策者的三条论证要点

第一，Agent 安全的最大单项风险不是技术漏洞，而是「不可见」——47% 的组织无法管控影子 AI，没有清单就没有防护。第二，投入的大头应放在 Gate 3（权限与围栏），因为设计型防御是唯一在面对自适应攻击时仍能保持有效性的防御族。第三，把门禁与 CI/CD 绑定，能让安全成本从「每次项目谈判」变成「流水线固定组成部分」，这是可持续的唯一路径。

第 9 章落地路线图：90 天企业实施路径

9.1分阶段实施计划

对于尚未建立系统化 Agent 安全能力的企业，建议按下述三个阶段推进。整体节奏的设计原则是：先建立可见性，再建立控制，最后建立持续运营。颠倒顺序是常见错误——在没有清单的情况下直接上控制工具，会导致控制覆盖率虚高而实际有效性极低。

表 9-190 天 Agent 安全能力建设路线图

阶段	时间	目标	关键交付物	成功判据
阶段一建立可见性	第 1–30 天	回答「我们有哪些 Agent、它们能做什么」	① Agent 台账（含责任人、业务用途） ② 工具与权限清单 ③ MCP / 组件依赖清单 ④ 数据流与信任边界图	清单覆盖率 100%；无未登记的影子 Agent；每个 Agent 有唯一责任人
阶段二建立控制	第 31–60 天	回答「我们如何限制 Agent 能做什么」	① 最小代理权四层控制落地 ② 工具调用前置规则引擎 ③ 人工审批点清单与审批界面 ④ 沙箱隔离部署 ⑤ 红队测试报告（含自适应攻击）	四层控制全部通过验证；自适应攻击下护栏 ASR ≤ 15%；全部高风险动作有审批
阶段三建立运营	第 61–90 天	回答「我们如何知道控制仍然有效」	① 全链路审计与日志基础设施 ② Agent 行为基线 ③ 熔断与回滚演练记录 ④ Agent 安全事件响应预案 ⑤ 再评估触发机制（与 CI/CD 绑定）	完成至少一次回滚与终止开关演练；审计日志完整可举证；再评估机制已写入发布流程

9.2组织与责任划分

表 9-2组织角色与门禁责任划分

角色	职责	在门禁中的位置
研发 / 产品团队	提供 Agent 清单与能力声明；执行修复；维护工具定义	Gate 0 自查；Gate 1 配合；修复闭环
安全团队（独立）	执行静态审查、红队测试、权限验证；出具评估结论	Gate 1–Gate 4 独立验证；有否决权
SRE / 平台团队	沙箱与隔离基础设施、审计日志、熔断与回滚机制	Gate 3 基础设施；Gate 4 观测能力
合规 / 法务	备案与登记、数据来源合规、跨法域映射声明	Gate 0 数据边界；Gate 1 许可与数据来源
业务负责人	风险接受决策（仅在正式例外流程中）；审批点责任人	例外审批；Gate 3 人工审批

独立验证权是这套机制的关键

门禁体系失效最常见的机制性原因，不是技术能力不足，而是安全团队在交付压力下失去了否决权。把「安全侧独立验证且拥有阻断发布权」写进流程制度，比任何技术控制都更重要——因为技术控制的有效性最终依赖于有人坚持执行它。

9.3常见落地障碍与应对

表 9-3常见落地障碍与应对策略

障碍	表现	应对建议
清单建不起来	业务团队认为登记是行政负担，配合度低；影子 Agent 持续出现	把 Agent 登记与 CI/CD 流水线绑定——未登记无法部署，从机制上消除影子 AI，而不是靠行政要求
测试强度衰减	红队测试由开发团队自测；在项目压力下测试用例被裁剪	建立独立红队职能；设置测试矩阵的最低用例数量作为硬性门槛，不允许协商
护栏过度自信	以静态测试结果作为上线依据，未做自适应攻击验证	在验收标准中明确写入「自适应攻击下 ASR 阈值」；用固定模板测出的数字不作为通过依据
效用与安全的两难	接入护栏后 Agent 任务完成率显著下降，业务方要求放宽	承认这是真实权衡而非可以消除的义务；优先选择效用损失更小的控制策略，并向业务方透明呈现权衡数据
变更后失守	上线后新增工具或升级模型，但未重新评估	把再评估触发条件写入发布流程，作为变更审批的必要检查项

第 10 章未来展望与优化方向

10.1标准体系的演进方向

当前最重要的一个事实是：面向 Agent 的控制标准尚未定稿，而 Agent 已经在生产环境运行。NIST 的 COSAiS 项目规划的「使用 AI Agent 系统」控制叠加层仍在起草，AI Agent Standards Initiative 于 2026 年 2 月才启动。这意味着在未来 12–24 个月内，企业将处在一个「先实践、后标准」的阶段。

这种状态的实务含义是：企业不能等标准出台再建能力，但也不应把自定义流程固化为不可迁移的形态。建议的策略是「以 OWASP Agentic Top 10 为风险主干，保留向 NIST 控制叠加层的映射接口」——风险分类稳定，控制实现可替换。当 NIST 的 Agent 控制叠加层发布时，企业可以通过映射而非重构来完成对齐。

10.2技术方向的三个确定性趋势

表 10-1三个确定性技术趋势及行动建议

趋势	判断依据	对企业的行动建议
设计型防御将成为主流	自适应攻击下检测型防御集体失效（ASR 78%–92%），而设计型防御保持 ≈15% 的水平。双 LLM 模式、CaMeL、FIDES、Progent 等方案已提供可复用模式。	优先投资架构级控制：信息流标签、能力追踪、权限控制层。把检测型防御定位为辅助而非主力。
Agent 身份体系标准化	NIST AI Agent Standards Initiative 明确聚焦 Agent 身份；四要素框架（Agent ID、能力声明、授权范围、委派链）已提出。	现在就为每个 Agent 建立独立身份与能力声明，即便标准未定稿——数据结构可迁移，缺失的基础数据无法补录。
供应链治理从「审查」走向「持续验证」	Rug Pull 型攻击（先正常后恶意）证明一次性审查不足；Smithery、Postmark 等事件显示注册表级投毒的现实性。	采用按哈希固定的持续校验机制，而非依赖初次审批。把工具描述变更纳入变更监控范围。

10.3尚待解决的问题

本报告在研究中识别出几个目前尚无成熟答案的问题，值得持续跟踪：

设计型防御的效用损失如何收敛	当前设计型防御（如双 LLM 架构）在有效性上占优，但代价是效用损失与工程复杂度。如何在不显著牺牲任务完成率的前提下实现架构隔离，仍是开放问题。
自适应攻击的标准化评测缺失	目前缺乏被广泛接受的、针对自适应攻击的标准化基准。企业在验收时难以给出一个有公信力的通过阈值。
多智能体级联失效的可控性	ASI08 所描述的级联失效在多智能体工作流中的传播动力学尚缺乏系统性研究，尤其是在 OT 等对确定性要求高的环境中。
Agent 行为基线的建立方法	如何为一个具有开放式任务空间的 Agent 定义「正常行为基线」，使其既能检出漂移又不产生大量误报，目前主要依赖经验而非方法论。
被污染记忆的可靠清除	ASI06 记忆投毒的持久性意味着「检测到污染」与「完全清除污染」之间存在差距，跨会话、跨副本的记忆一致性清理尚无成熟方案。

10.4本报告的核心结论

回到研究起点提出的问题——在 Agent 正式上线之前，安全团队究竟应当检查什么、按什么顺序检查、以什么作为通过标准？本报告的答案可以归结为三句话：

结论一：检查什么

以 OWASP Agentic Top 10 的 ASI01–ASI10 为风险主干，优先聚焦发生在「模型决策与系统执行交界处」的三类高风险：目标劫持（ASI01）、工具滥用（ASI02）、非预期代码执行（ASI05）。同时把供应链（ASI04）作为独立审查线，因为在 MCP 生态中它的实际发生率最高。

结论二：按什么顺序

按「先可见、再控制、后运营」的顺序推进：Gate 0 建立资产可见性是全部门禁的索引基础；Gate 1–Gate 3 建立从静态审查到权限围栏的控制体系；Gate 4–Gate 5 把安全状态从「一次性认证」转为「持续属性」。颠倒顺序会导致控制覆盖率虚高而实际无效。

结论三：以什么作为通过标准

以可复核的证据，而非自评声明。具体来说：一条真实的工具调用审计日志、一次在自适应攻击下仍被阻断的记录、一次真实完成的回滚与终止开关演练、一份与运行时配置一致的机器可读能力声明。NIST AI RMF 实践中最深刻的教训是——把框架翻译成勾选项，产出的只是关于现实的声明，而不是关于现实的测量。

最后需要强调的是本报告反复出现的一个判断：Agent 不是聊天机器人，而是拥有 API 权限的数字员工。给予一个特权员工的身份控制、最小权限、持续监控与应急预案，这些工作企业已经做了几十年。Agent 安全的新颖之处在于攻击面的形态——它由自然语言构成，传统安全工具在其中完全失明；而它的解决路径并不新颖，仍然是那些被反复验证过的基本原则：最小权限、纵深防御、默认拒绝、以及可审计。

附录 A引用数据溯源表

本报告坚持数据溯源原则。下表列出全部关键定量数据的原始出处，供复核。对于无法追溯到一手来源的数据，已在正文中做虚化处理或明确标注为「估算区间 / 示例基线值」。

表 A-1关键定量数据溯源表（✓ 可溯源 / △ 估算或分析模型）

#	数据内容	数值	来源	可溯源
1	EchoLeak 漏洞严重度	CVSS 9.3（研究机构口径）/ 7.5（NIST NVD）	CVE-2025-32711；Microsoft MSRC 安全更新指南；NIST NVD	✓ 一手
2	EchoLeak 披露时间	2025 年 6 月 11 日（服务端已修复）	Microsoft MSRC 公告	✓ 一手
3	OWASP Agentic Top 10 发布时间	2025 年 12 月 9 日	OWASP GenAI Security Project（100+ 贡献者，NIST/Cisco/Microsoft/AWS 评审）	✓ 一手
4	OWASP Agentic Top 10 排序方法	社区投票 75% + 事故数据 25%	OWASP GenAI Security Project；事故语料 7,714 起（6,639 起可分类）	✓ 一手
5	MCP 生态服务器数量增长	714（2024 年末）→ 16,000+（2026 年初），约 22 倍	MCP 生态公开统计	✓ 公开统计
6	MCP Server 存在安全问题比例	66%（扫描 1,808 个）	AgentSeal 扫描报告	✓ 公开研究
7	官方 MCP 参考实现无认证比例	41%	AgentMarketCap 分析	✓ 公开分析
8	10 个 MCP 插件栈被利用概率	92%	VentureBeat 对生产 MCP 栈的分析	✓ 公开分析
9	MCP 漏洞类别分布	Shell/exec 注入 43%、工具链缺陷 20%、认证绕过 13%、路径穿越 10%、其他 14%	公开 CVE 数据集统计（2025–2026）	✓ 公开统计
10	MCP 漏洞披露节奏	2026 年 1–2 月 60 天内 30+ 枚；1–4 月累计 40+ 枚，约每 4 天 1 枚	公开 CVE 统计；多来源汇总	✓ 公开统计
11	路径穿越脆弱实现比例	82%（基于 2,614 个实现调研）	公开实现调研	✓ 公开研究
12	代码注入风险 API 使用比例	67%	公开实现调研	✓ 公开研究
13	静态注入无防御攻击成功率	46.5%（144 用例）	AgentDojo Banking 套件，gpt-4o-mini，important_instructions 攻击	✓ 可复现基准
14	输入分类器静态攻击 ASR	12.0%（分区策略 0.7%）	AgentDojo 实测（单模板，不可外推）	✓ 可复现基准
15	自适应攻击下检测型防御 ASR	78%–92%；12 项已发表防御 >90%	Nasr et al., The Attacker Moves Second	✓ 公开研究
16	Extract-and-Evaluate 监控器 ASR	95.5%（Mistral-7B 作为监控 LLM）	Agent-as-a-Proxy 攻击研究	✓ 公开研究
17	InjecAgent 无防御 ASR	约 24%（ReAct 提示的 GPT-4 Agent，1,054 测试用例）	InjecAgent 基准	✓ 可复现基准
18	AgentDojo 规模	97 个真实任务 / 629 个安全测试用例	AgentDojo 基准	✓ 可复现基准
19	2026 公开红队竞赛规模	464 名参与者、272,000 次攻击、8,648 次成功、41 个场景、13 个前沿模型	2026 公开 Agent 红队竞赛报告	✓ 公开报告
20	模型攻击成功率区间	0.5% – 8.5%（全部模型均存在脆弱性）	同上	✓ 公开报告
21	StruQ / SecAlign 效果	StruQ <2%（非优化攻击）；SecAlign 优化型攻击 <15%	StruQ、SecAlign 论文	✓ 公开论文
22	组织存在危险 Agent 行为比例	80%（含未授权系统访问与不当数据暴露）	AIUC-1 Consortium / Stanford Trustworthy AI Research Lab（2025）	✓ 公开研究
23	无法管控影子 AI 的组织比例	47%	行业调研	✓ 公开调研
24	被植入漏洞的 Agent 框架组件数	43 个	Barracuda Security 报告（2025 年 11 月）	✓ 公开报告
25	中国生成式 AI 备案与登记累计数	截至 2026-08-31：备案 1,112 款；登记 731 款	国家互联网信息办公室公告（2026-09-14）	✓ 官方公告
26	中国生成式 AI 备案阶段数据	2026-06-30：备案 988 款、登记 598 款	国家网信办公告（央视网转载，2026-07-10）	✓ 官方公告
27	中国网信办第一阶段执法处置量	累计处置违规 AI 产品 3,500 余款	公开报道（中国经济新闻网）	✓ 公开报道
28	EU AI Act 处罚上限	3,500 万欧元或全球年营业额 7%（取较高者）	EU AI Act 法规文本	✓ 法规原文
29	EU AI Act 高风险截止日调整	Annex III：2027-12-02；Annex I：2028-08-02	Digital Omnibus on AI（欧洲议会 2026-06-16 通过 423:57，理事会 2026-06-29 批准）	✓ 立法记录
30	EU AI Act 未推迟项	Article 50 透明度义务与 GPAI 处罚机制 2026-08-02 生效	EU AI Act 法规文本 + Digital Omnibus 修订	✓ 法规原文
31	NIST AI Agent 标准进展	AI Agent Standards Initiative 于 2026 年 2 月启动	NIST 人工智能标准与创新中心	✓ 官方信息
32	NIST AI RMF 版本状态	AI RMF 1.0 仍为现行版本（2.0 尚未发布）；AI 600-1 为生成式 AI Profile	NIST AI RMF 官方页面 / AI 600-1（2024-07-26）	✓ 官方信息
33	缺陷发现阶段成本倍率	上线后 10–50×；被外部披露 50×+	行业实践估算区间（相对量级，非精确测算）	△ 估算值
34	就绪度与风险矩阵坐标	六维就绪度、风险矩阵定位坐标	本报告基于框架与实证数据构建的分析模型	△ 分析模型

溯源说明：标记为「✓」的数据可追溯至公开的一手来源（法规原文、CVE 记录、官方公告、可复现基准或公开论文），读者可通过检索对应来源复核。标记为「△」的数据为本报告的估算区间或分析模型输出，用于表达相对关系与量级，不作为精确测算引用。

附录 B上线前安全检查清单（Checklist）

本清单为第 7 章门禁方法的可执行化摘要，可用于项目自查。每项均标注了对应的风险编号（OWASP ASI）与证据要求。建议作为发布评审的必要附件。

B.1Gate 0资产与身份登记

#	检查项	对应风险	证据要求	通过
0.1	Agent 台账完整，含名称/版本/责任人/业务用途/部署环境	全部	清单覆盖率 100%	☐
0.2	每个 Agent 有机器可读的能力声明	ASI02 / ASI03	能力声明文件与运行时配置一致	☐
0.3	工具与权限清单完整，标注权限级别与数据分类	ASI02	工具清单 + 权限矩阵	☐
0.4	MCP Server / 插件 / 第三方组件依赖清单	ASI04	依赖清单含来源、维护方、版本、哈希	☐
0.5	每个 Agent 有独立、可轮换的身份凭证	ASI03	无 Agent 复用人类凭证；有明确过期时间	☐
0.6	数据流与信任边界图已完成	ASI01 / ASI06	标注全部跨信任边界的数据交换点	☐

B.2Gate 1静态合规与供应链审查

#	检查项	对应风险	证据要求	通过
1.1	无硬编码凭证 / API Key / 密钥	ASI03 / MCP01	静态扫描报告（无高危发现）	☐
1.2	无生产环境宽松默认配置（如监听 0.0.0.0、默认口令）	MCP07 / MCP09	配置审查记录	☐
1.3	依赖项按哈希固定，SBOM 已生成且无未修复高危 CVE	ASI04 / MCP04	SBOM + 漏洞扫描报告	☐
1.4	全部 MCP Server 在批准清单中，且完整审查了工具描述 JSON Schema	ASI04 / MCP03	工具描述审查记录	☐
1.5	远程 MCP 连接使用 OAuth 2.0，拒绝环境变量静态 Key	MCP01 / MCP07	认证配置证据	☐
1.6	调试端点（Inspector 类）未暴露公网；私网地址访问受控	MCP05	网络暴露面扫描结果	☐
1.7	数据来源合法、许可合规、来源可追溯	合规	数据来源说明文档	☐

B.3Gate 2对抗性红队测试

#	检查项	对应风险	证据要求	通过
2.1	间接提示注入测试覆盖全部外部数据源类型	ASI01	每类 ≥10 用例，无成功外泄/越权	☐
2.2	已执行自适应（定向优化）攻击测试，而非仅静态模板	ASI01	≥20 个迭代优化用例；ASR ≤15%	☐
2.3	目标劫持测试覆盖多步任务场景	ASI01	目标偏移在执行前被阻断	☐
2.4	工具滥用测试：破坏性参数 + 非预期工具串联	ASI02	危险参数被规则引擎拦截记录	☐
2.5	代码执行逃逸测试：沙箱逃逸 / eval 滥用 / 路径穿越 / 符号链接	ASI05	≥15 用例，全部被阻断并告警	☐
2.6	记忆投毒测试验证跨会话影响	ASI06	≥10 跨会话用例，投毒被检出或无效	☐
2.7	供应链植入测试：工具描述篡改 + Rug Pull 模拟	ASI04	描述变更被检测；哈希校验失败即阻断	☐
2.8	测试在真实 Agent 运行时与真实工具集上执行（非仅单元测试）	全部	集成测试报告 + 环境状态验证结果	☐
2.9	红队测试由独立团队执行	流程	独立团队签署的测试报告	☐

B.4Gate 3权限与围栏验证

#	检查项	对应风险	证据要求	通过
3.1	L4 意图层：系统策略不可被外部内容覆盖	ASI01	覆盖尝试失败记录	☐
3.2	L3 能力层：工具白名单 + 参数强校验 + 动作前置规则引擎	ASI02	越界参数被阻断的测试记录	☐
3.3	L2 身份层：独立短期凭证、与用户身份解耦、作用域最小化	ASI03	凭证配置审查 + 有效期核验	☐
3.4	L1 执行层：容器/微虚拟机隔离、非 root、网络收敛	ASI05	沙箱逃逸测试失败记录	☐
3.5	高风险动作（对外通信/资金/代码执行/删除/权限变更/记忆写入/记录更新）已设人工审批	ASI02 / ASI09	审批点清单 + 界面截图	☐
3.6	审批界面完整呈现动作、目标、数据源、理由且不可被裁剪	ASI09	审批界面验证记录	☐
3.7	工具输出被标记为不可信数据，经净化后进入模型上下文	ASI01 / MCP10	数据流处理证据	☐

B.5Gate 4观测、审计与回滚演练

#	检查项	对应风险	证据要求	通过
4.1	全链路审计：记录全部工具调用、上下文变更、Agent-用户交互	ASI08 / MCP08	日志完整性抽样验证；仅追加存储	☐
4.2	决策按风险等级记录相应推理轨迹（三级分级）	ASI09	三类决策样本记录粒度验证	☐
4.3	熔断机制：速率限制、超时、预算上限、异常行为熔断器	ASI08	熔断实测触发记录与响应时间	☐
4.4	关键动作可回滚，且已实际演练	ASI08	≥1 次真实回滚演练记录	☐
4.5	终止开关（Kill Switch）有效，已实测	ASI10	终止开关实测记录与生效延迟	☐
4.6	异常行为告警可送达值班人员；有 Agent 事件响应预案	ASI10	桌面推演记录 + 告警送达验证	☐

B.6Gate 5灰度发布与持续再评估

#	检查项	对应风险	证据要求	通过
5.1	影子流量验证：先以只读/建议模式运行并与人工结果对比	全部	对比分析报告	☐
5.2	金丝雀发布：分阶段放量，每阶段有明确观测指标与回滚条件	全部	发布计划 + 阶段观测记录	☐
5.3	Agent 行为基线已建立（工具调用分布、动作频率、数据访问模式）	ASI10	基线模型文档	☐
5.4	再评估触发条件已写入发布流程（新增工具/权限变更/模型升级/安全事件/场景变化）	全部	流程文档 + CI/CD 集成证据	☐
5.5	定期复核机制（建议季度）已明确责任人与范围	全部	复核计划文档	☐
5.6	已完成合规公示要求（模型名称、备案号或上线编号）	合规	产品页面公示截图	☐