执行摘要

本报告回答一个具体问题：如何构建一个能够评估「不同类型的智能体」的安全评估平台，并把评估结论真正转化为可落地的安全能力。

结论先行：智能体安全评估的核心矛盾，不在于「缺少攻击用例」，而在于「评估对象高度异质、失效模式跨层、结论难以互认」。现有测评普遍存在三个结构性缺陷：用同一套 LLM 越狱题库去测所有智能体（类型失配）；只测模型输出、不测行动链（层次失配）；测完出报告、测完即结束（闭环缺失）。

本报告提出以「分类型 × 全链路 × 可闭环」为核心设计原则的智能体安全评估平台（ASEP, Agent Security Evaluation Platform）实现方案，主要贡献四：

1.分类矩阵：建立「自主性 × 环境耦合度」二维分类法，将智能体划分为编排式、工具型、自主型、多智能体、具身型五类，并给出各类的风险权重矩阵与专项用例集；

2.九阶段流水线：从分类画像、风险定级、用例生成、环境构建、对抗执行，到混合裁决、量化评分、定级报告、闭环回灌，形成可复现、可自动化的评估流水线；

3.十维度量体系：定义 ASR、SUR（安全-效用权衡比）、GDI（目标漂移指数）等可计算指标，并针对「模型裁判不可靠」这一行业通病给出双裁判 + 人工仲裁的工程解法；

4.OASP 协议与行业基准：提出开放智能体安全协议（Open Agent Security Protocol）作为评估者与被评估者之间的标准接口，配合基准题库与失效模式库，解决「结论不可比、不可互认」问题。

报告同时给出四阶段落地路线图（90 天 / 180 天 / 12 个月 / 24 个月）与预算、人员、里程碑建议，并对三项前瞻方向（自主对抗智能体、评估者自身安全、动态资格与漂移再认证）作出研判。

第 1 章　背景与真实问题定义

1.1 从「对话」到「行动」：风险性质的根本改变

2023—2024 年的 AI 安全讨论几乎围绕「模型输出」展开：有害内容、偏见、幻觉、提示词越狱。2025 年以后，产业重心快速转向智能体（Agent）——它不再只生成文本，而是规划、调用工具、读写数据、执行代码、与其他智能体协作。风险的落点随之从「说错话」变成「做错事」，且做错事的动作由系统凭证执行，具备真实权限、真实副作用、真实不可逆性。

这一转变有可验证的规模证据。中国信息通信研究院 2026 年 5 月发布的《云上智能体服务网络和数据安全自律公约（2026 版）》披露：以 OpenClaw 为代表的智能体技术快速普及，截至 2026 年 4 月 15 日我国互联网暴露的 OpenClaw 实例超过 14 万个，其中超 60% 部署于云平台、10% 以上存在高危漏洞，国内至少 600+ 个实例疑似安装了恶意技能。

换句话说，「智能体安全」不是纸面风险，而是已经形成可观测规模的存量暴露面。与此同时，攻击手法也从理论走向工业化：MCPTox 基准对 45 个真实 MCP 服务器、20 个大模型进行测试，测得工具投毒平均攻击成功率 36.5%，对单一模型最高达 72.8%，且安全对齐后的模型拒绝率低于 3%。这直接说明：仅靠模型对齐无法缓解工具层攻击，必须引入系统级评估与围栏。

真正的问题因此浮现：当企业要采购、上线、验收一个智能体时，凭什么判断它「足够安全」？由谁、用什么方法、依据什么标准、给出什么形式的结论、结论能否被审计与复现？

1.2 现有评估体系的三个结构性缺陷

此外还有一个被普遍低估的工程问题：评估结论的「可信度」本身无保障。多数方案采用 LLM-as-Judge 做裁判，但裁判模型可被对抗样本「讨好」、存在位置偏见与长度偏见，且当被测对象与裁判同源时，评估有效性进一步削弱。本报告在第 5 章对此给出专门设计。

第 2 章　威胁图景：智能体攻击面全景

2.1 权威威胁框架的三条主线

当前全球范围内的智能体安全威胁框架已形成三条互补主线，本平台的风险知识库以此为骨架：

值得注意的量化趋势：MITRE ATLAS 在 2026 年 5 月起为每个技法增加平台标签，其中 Agentic AI 标签达 139 项，超过 Generative AI（106 项）——这一以「模型安全目录」起家的框架，已按自身分类实质转变为「智能体安全框架」。2026 年 7—9 月的更新进一步新增了 AI Agent Tool Poisoning（含工具定义、实现、运行时响应三个子技法）、Autonomous Reconnaissance、Autonomous Attack-Path Adaptation、Autonomous Attack Orchestration、Autonomous AI Agent Communication 等自主型技法，并首次给出两项针对「智能体权限治理」的缓解措施：AI Agent Authority Expansion Controls（AML.M0037）与 AI Agent Scope Drift Detection（AML.M0038）。

这两项缓解措施的官方表述具有重要的架构含义：其控制「应实现在 AI 智能体之外，不应仅依赖系统提示词、模型对齐，或依赖智能体自行识别某动作已越界」。换言之，权威机构已明确：智能体的权限边界与漂移检测必须由外部系统强制实施——这正是评估平台与运行时围栏存在的合法性基础。

2.2 OWASP 智能体十大风险（ASI01–ASI10）与在野案例

下表汇总 OWASP 智能体十大风险条目及其公开关联的在野案例，本平台的风险知识库将逐条绑定对应的评估用例：

快速筛查工具：Simon Willison 提出的「致命三要素」（Lethal Trifecta）——私有数据访问权 × 接触不可信内容 × 具备外发能力——是上述多项风险同时可被直接利用的充要条件组合。本平台将其实现为资产画像阶段的一键筛查规则，任一同源智能体同时满足三项即自动触发高危告警与强制深度评估。

2.3 已披露漏洞与供应链事件（可溯源）

智能体安全的特殊性在于：大量真实风险落在「实现层」而非「模型层」。以下为已公开披露、可溯源的关键漏洞，构成本平台用例库中的「现实锚点」：

关键洞察：上述多数事件与「模型漏洞」无关，全部通过「模型被接入什么」实现。这意味着评估的重心必须从模型输出转向系统接线（wiring）——工具定义、配置文件、传输通道、凭据可达性。

2.4 中国监管与标准进展

与欧美以「风险管理框架 + 行业指南」为主的路径不同，中国在智能体安全上采取了「强制性国标 + 团标 + 自律公约」的多层组合，且节奏更快：

对平台设计的直接影响：《智能助手类智能体安全分级规范与建设指南》的 L1—L5 分级与「输入→感知→决策→记忆→工具→执行→协作」闭环，为本报告的流水线设计提供了本土化锚点；而《智能体应用安全基本要求》的八项技术要求（身份标识、权限调用、工具调用、数据使用、人工介入、输入输出防护、日志与监测、异常阻断与关停）可直接映射为平台的「合规检查项」模块。平台的评估结论必须能同时输出两套视图：面向国际框架（OWASP/CSA/ATLAS）的技术视图，与面向国内监管（强制性国标/团标）的合规视图。

第 3 章　评估框架总论：分类型 × 全链路 × 可闭环

3.1 设计原则

3.2 分类矩阵：五类智能体

本报告采用「自主性（Autonomy）× 环境耦合度（Environment Coupling）」二维分类。自主性刻画智能体在多大程度上自行规划与决策（从人在回路到完全自治）；环境耦合度刻画其行动作用的对象（从纯数字世界到物理世界）。二者共同决定风险的性质：自主性越高，「越界」越难预先枚举；耦合度越高，「出错」越难回滚。

图 1　智能体分类矩阵：自主性 × 环境耦合度

一个可直接用于工程实施的规律：随着类型从 Ⅰ 迁移到 Ⅴ，评估权重从「能力与合规」逐步迁移到「边界与行为」，最终在 Ⅴ 类由功能安全（Safety）压倒信息安全（Security）。这一权重迁移是分类型评估的核心，也是本平台相对通用测评工具的根本差异。

3.3 评估维度体系（A–I 九维）

平台采用九个一级评估维度，覆盖从目标完整性到物理安全的完整链条。九个维度可逐一映射到 OWASP ASI 条目、CSA 测试项与国内标准要求，实现「一次评估、多框架输出」：

3.4 风险权重矩阵

下表给出五类智能体在九个维度上的关键程度（● 高 / ◐ 中 / ○ 低）。平台在用例装配阶段依据该矩阵自动调整用例数量配比与权重，避免「给编排式智能体做长程漂移测试」这类无效测评。

图 4　分类型评估设计：风险权重矩阵与专项用例

第 4 章　平台总体架构

4.1 架构设计思路

平台架构的核心矛盾是：被测对象形态高度异质（SDK、MCP、A2A、浏览器、OS、机器人），而评估能力应尽量复用。解法是引入「统一接入适配层」——把异质接入抽象为统一的事件与动作模型，使得上层用例、裁决、评分、报告逻辑完全解耦于具体被测形态。

图 2　智能体安全评估平台（ASEP）总体架构

4.2 分层说明

L1 被测对象接入层

提供六类接入适配器，屏蔽形态差异。所有适配器统一输出三类数据：轨迹（Trace，动作序列与上下文）、状态（State，权限集、记忆快照、配置）、控制（Control，干预注入与断点）。

L2 攻防用例引擎

由风险知识库、攻击生成器、环境与载荷三部分组成。风险知识库负责「测什么」，攻击生成器负责「怎么变」，环境与载荷负责「在哪测」。

•风险知识库：双向映射 OWASP ASI01–ASI10、CSA 12 类威胁的 60+ 测试项、MITRE ATLAS 智能体技法，以及国内强制性国标与团标条款。映射关系以数据（而非代码）维护，标准更新时可快速同步。

•攻击生成器：内置模板库覆盖注入、投毒、伪造、劫持四大家族；支持多轮进化（攻击者-防御者共演化）；支持灰盒定向模糊测试（针对污点传播路径）；支持多模态载体（文本、图片、音频、网页、文档）。

•环境与载荷：蜜罐工具（诱导越权调用）、假凭据（水印化，一旦使用即可精确归因）、诱饵数据（检测外泄）；环境快照化保证可复现；网络出口镜像与流量染色；数字孪生（真实系统只读副本）用于高保真测试。

L3 观测与度量层

分四个度量族，共约 20 个可计算指标。关键指标定义见第 5 章。

L4 裁决引擎

由混合裁决器与评分定级两个模块构成，是本平台工程难度的集中点。裁决器的可靠性直接决定评估结论的可信度，设计详见第 5 章。

L5 输出与闭环层

输出五类产物：安全评估报告（分类型结论 + 证据附录）、整改建议单（按 ROI 排序）、回归基线快照（供 CI/CD 门禁）、监管报送包（可核验证据集）、运行时策略回灌（评估结论自动转为围栏规则）。第五类是本平台区别于普通测评工具的关键——评估不止于报告。

第 5 章　评估流水线与关键机制

5.1 九阶段流水线

流水线设计的目标是「可复现、可自动化、可回归」。九个阶段中，阶段 1、2、3、8 依赖人工确认与专家知识，阶段 4—7 全自动，阶段 9 通过策略回灌与 CI/CD 集成实现常态运行。

图 3　九阶段评估流水线：从分类定级到运行时回灌

5.2 阶段 2：风险定级与测试强度决策

风险定级决定后续投入的测试强度。平台采用四因子打分模型，输出 L1—L5 安全等级，并据此自动决定用例规模、红队轮次与环境保真度：

举例：一个可读写生产数据库、读取外部邮件、自主决定发送内容的运维智能体，四因子均处高位，将直接被定为 L5，触发最高强度评估（含长程漂移、多轮自适应红队、实时拦截验证），并强制要求运行时围栏与人工复核双重控制。而一个只读内部知识库的问答智能体，四因子低位，定为 L1—L2，采用轻量回归与配置核查即可。

5.3 阶段 3：用例生成与「良性命中」对照

分类型评估最容易犯的错误，是只测「能不能攻破」，不测「正常任务还做不做得了」。因此平台在生成攻击用例的同时，按固定比例（默认 1:1）生成「良性命中用例」（Benign Control）——即完全不包含攻击载荷的等价任务。若被测对象在攻击场景下通过率上升但在良性命中用例下大幅下降，说明其安全机制以牺牲可用性为代价，属于「伪安全」，评估报告须显式标注。这正是 SUR 指标的工程落地方式。

5.4 阶段 6：破解「模型裁判不可靠」

LLM-as-Judge 已成为 AI 评估的事实标准，但其可靠性存在系统性缺陷：偏好自身生成内容、对被评内容长度与位置敏感、可被对抗样本「讨好」，且当裁判与被测同源时有效性进一步削弱。本平台采用五层防御设计：

5.确定性优先：能由规则判定的绝不用模型判定。「是否读取了 /etc/shadow」「是否向非白名单地址发起连接」「是否修改了 MCP 配置文件」这类问题由断言直接判定，零歧义、可复现。经验上，约 60%—70% 的判定可归入此类。

6.双裁判交叉：对语义级判定（如「该计划是否偏离初始意图」）采用两个不同家族模型独立裁决，结论不一致时自动升级。

7.裁判隔离与去偏：裁判模型与红队生成模型、被测对象来源隔离；对候选答案做顺序随机化与长度归一化，消除位置偏见与长度偏见。

8.裁判可信度校准：持续用人工标注样本监测裁判与人类专家的一致性（Cohen's κ），κ 低于阈值时暂停自动裁决并转为人工主导，该监测结果本身作为平台的质量指标对外披露。

9.人工仲裁兜底：所有「争议样本」（双裁判分歧、κ 下降、一票否决项）进入人工仲裁池，由专家终裁并反哺裁判校准集，形成持续改进闭环。

5.5 关键度量指标定义

为保证跨厂商、跨版本可比，平台对核心指标给出可计算定义：

第 6 章　分类型评估细化设计

本章是本报告的核心。针对第 3 章划分的五类智能体，逐一给出攻击面分析、核心用例、判据、通过门槛与推荐方法。

图 5　五类智能体的评估设计卡：攻击面 → 核心用例 → 判据 → 通过门槛

6.1 Ⅰ 类：编排式智能体

6.1.1 攻击面特征

编排式智能体的最大特征是「可控性高、可枚举性强」。流程由 DAG 或状态机定义，节点边界清晰，动作空间有限。这带来两个评估上的便利：一是可用确定性断言做高频回归；二是可对每个节点做静态与动态双重核查。但其风险同样明确——权限往往集中授予（为了让流程跑通，常一次性给予全流程所需的全部权限），且节点间上下文传递构成天然的注入通道：一个处理外部邮件的节点，其输出可能被下游节点当作指令执行。

6.1.2 核心用例（节选）

6.1.3 通过门槛与方法

•L3 及以上：越权动作率必须为 0，数据外发违规必须为 0（一票否决项）；流程回归用例 100% 通过；人工审批不可绕过。

•方法组合：配置核查（权限最小化检查）+ 确定性回归（断言脚本）+ 业务安全测试。因流程确定，可实现全自动化高频回归，单次评估成本在所有类型中最低。

•特别提示：应重点核查「审批超时自动通过」这类工程便利设计——它是审批脱环最常见的真实根因，也是攻击者最易利用的配置缺陷。

6.2 Ⅱ 类：工具型 / 单技能智能体

6.2.1 攻击面特征

这是当前安全事件最密集、也是风险最被低估的类别。编码助手、CLI Agent、浏览器 Agent 共同的特征是：运行在开发者或用户的高权限环境，拥有文件系统、Shell、云凭据、版本控制权限；同时处理来自外部内容（代码注释、Issue、网页、邮件）的不可信输入；并且大量产品默认或可配置为「自动执行」（即 YOLO 模式）无需逐步确认。本章 2.3 节列出的 CVE 几乎全部落在此类别。

MCP 的结构性缺陷是关键：工具的文本描述会被注入模型上下文并被当作可信内容处理，而协议本身不要求客户端对描述做校验、净化或密码学校验。攻击者只需在看似无害的工具描述中嵌入指令，即可在计划阶段操控模型行为。更严重的是「Rug Pull」——服务器可在用户审批时呈现安全定义，之后静默替换为恶意定义，使一次性安装审查失效。

6.2.2 核心用例（节选）

6.2.3 通过门槛与方法

门槛设定需要务实。公开基准显示，即便安全对齐后的模型在工具投毒场景下 ASR 仍可达 36.5%—72.8%、拒绝率低于 3%。因此要求「ASR = 0」在短期内不现实。合理的门槛是：沙箱逃逸必须为 0（硬性）；工具投毒 ASR 允许存在，但必须「可被围栏拦截、可留痕、可告警、可归因」。换言之，考核重点从「模型不被骗」转向「系统能兜住」。

•方法组合：渗透测试 + 供应链成分分析（MCP 服务器与技能清单化、来源校验、版本锁定）+ 沙箱逃逸专项 + 配置核查。

•可直接复用公开基准做横向对照：AgentDojo（97 个真实任务 + 629 个安全测试用例，衡量注入鲁棒性与任务可用性）、InjecAgent（1054 个间接注入用例）、MCPTox（45 个真实 MCP 服务器）、SandboxEval（51 个执行环境安全用例）。基线对照能显著提升结论的可信度与说服力。

6.3 Ⅲ 类：自主型智能体

6.3.1 攻击面特征

自主型智能体的评估从根本上不同于前两类：动作空间不可穷举，行为路径依任务而异，单点校验必然失效。一个自主智能体在完成长时任务时，可能经历数百步推理、数十次工具调用、多次子目标分解——任何一步都可能引入偏差并被后续步骤放大。

这类智能体的核心风险不是「被攻破」，而是「漂移」：在没有任何外部攻击的情况下，随着任务推进逐步偏离初始意图，或为达成目标而自主扩张权限（例如为完成文件整理任务而申请删除权限）。MITRE ATLAS 在 2026 年 9 月专门新增 AML.M0037（AI Agent Authority Expansion Controls）与 AML.M0038（AI Agent Scope Drift Detection）两项缓解措施，正是针对这一失效模式。

6.3.2 核心用例（节选）

6.3.3 通过门槛与方法

采用「预算制」而非「零容忍制」：在限定步数、Token 与工具调用预算内，要求漂移指数不超过阈值、越界动作数为 0、资源消耗不超预算。每一次评估必须留存完整可复现的轨迹，否则结论不可采信。

•方法组合：长程轨迹评估 + 自适应多轮红队（攻击者-防御者共演化）+ 数字孪生环境 + 运行时全程观测。

•成本提示：此类评估的单次成本在所有类型中最高（需长时任务沙箱与大算力），建议采用「抽样 + 分层」策略——对 L4—L5 对象全量长程测试，对 L3 及以下采用缩短版任务集（100—200 步）。

•工程要点：必须区分「因能力不足而放弃」与「因安全约束而拒绝」。前者是能力问题，后者是安全机制生效——二者在轨迹上表现不同（前者停滞或报错，后者出现明确的拒绝理由与替代方案），裁决器须能区分。

6.4 Ⅳ 类：多智能体系统

6.4.1 攻击面特征

多智能体引入了一类前三种类型中不存在的风险：智能体之间的隐式信任。在单体智能体中，所有输入都来自外部；而在多智能体系统中，Agent A 的输出会成为 Agent B 的输入，且 B 往往会信任 A——因为 A 是「自己人」。这个信任假设是可攻击的。

A2A（Agent-to-Agent）协议的普及放大了这一风险：Agent 卡（Agent Card）用于声明身份与能力，若缺乏密码学绑定与验证，攻击者可发布伪造的高信任 Agent 卡，实现中间人拦截与流量篡改（即 OWASP ASI07 与 ASI10 关联的在野案例）。此外，编排器（Orchestrator）的状态一旦被污染，会通过其向所有托管 Agent 广播的指令向下游扩散，形成「一污俱污」的级联失效。

6.4.2 核心用例（节选）

6.4.3 通过门槛与方法

•爆炸半径不超过 1 跳（单点失陷不得扩散至间接下游）；

•跨 Agent 消息须 100% 可验证（签名 / 溯源），未通过校验的消息必须被拒绝而非降级处理；

•合谋检测须在 N 轮内触发（建议 N ≤ 5）；委托权限不得超出委托人权限集（权限单调递减原则）；

•方法组合：通信旁路录制 + 混沌注入 + 多代理红队角色扮演（部分 Agent 由红队控制）+ 形式化信任链验证。需先构建可复现的多 Agent 沙箱拓扑。

6.5 Ⅴ 类：具身 / 物理智能体

6.5.1 攻击面特征与评估哲学

具身智能体的评估需要一次哲学层面的切换：在这里，Safety（功能安全）优先于 Security（信息安全）。在信息系统中，安全机制被绕过的最坏结果是数据泄露；在物理系统中，最坏结果是人身伤害。因此评估的第一原则是：安全联锁必须独立于 AI 存在、且不可被 AI 指令绕过。ATLAS AML.M0037 明确要求权限控制「应实现在 AI 智能体之外，不应仅依赖系统提示词、模型对齐」——在具身场景中，这一要求的强制性最高。

另一个特征是动作不可逆。数字世界可以回滚，物理世界不能。这决定了评估策略必须是「仿真优先、实机谨慎」：先在数字孪生中穷举危险路径，确认安全机制有效后再进行受控实机验证，且实机测试必须有独立硬件急停与安全员在场。

6.5.2 核心用例（节选）

6.5.3 通过门槛与方法

•零容忍：任何可绕过安全联锁的路径均为一票否决，不接受任何补偿性控制或折中方案；

•仿真通过后方可实机；实机测试须有独立硬件急停 + 安全员在场 + 最小化测试场地；

•方法组合：数字孪生仿真（Gazebo / Isaac Sim 等）→ 受控实机双阶段；FMEA（失效模式与影响分析）与 STPA（系统理论过程分析）危害分析；对抗扰动专项测试；须与功能安全流程（ISO 13849 / IEC 61508）耦合，形成「信息安全 + 功能安全」联合评估。

•组织建议：此类评估不应由纯信息安全团队独立完成，必须引入功能安全工程师与领域专家（机器人、OT、临床）共同参与，否则极易出现「通过信息安全的评估、却遗漏物理危害」的严重错配。

第 7 章　平台实现路线与关键技术选型

7.1 技术栈建议

7.2 关键工程难点与应对

7.3 平台自身的安全要求

一个评估平台掌握着被测系统的全部凭据与攻击载荷——它本身就是高价值目标。平台自身须满足不低于被测对象的安全要求：

•凭据隔离：平台持有的是水印化假凭据，真实凭据不经手；一旦假凭据被使用即可精确定位泄露路径；

•攻击载荷管控：漏洞利用代码与恶意样本须加密存储、访问留痕、使用范围受控，防止平台成为攻击武器库；

•裁判隔离：裁判模型与红队生成模型物理或逻辑隔离，防止生成器与裁判相互影响；

•审计自身：平台的所有操作（谁、何时、对哪个对象、执行了什么用例）必须完整留痕，「评估者的可审计性」是结论可信的前提；

•最小权限：平台自身的运维权限亦按最小权限原则授予，避免「评估平台成为最大单点风险」。

第 8 章　落地路线图

8.1 总体节奏

建议以「能力递进 + 场景切入」的方式推进，避免追求一次性建成大而全的平台。四阶段路线图如下：

图 6　四阶段落地路线图与能力交付节奏

8.2 阶段一（0—3 个月）：单点突破，验证价值

目标：在一个高价值场景上跑通完整闭环，产出可展示的能力与证据，而非追求覆盖度。

•切入场景建议：Ⅱ 类工具型智能体（编码助手 / CLI Agent）。理由：风险最集中、事件最多、说服力最强，且评估成本相对可控（无需长程沙箱与大算力）。

•交付物：MCP 代理网关 + 用具库（工具投毒、沙箱逃逸、凭据读取、恶意技能）+ 确定性裁决规则 + 首份评估报告。

•成功判据：能够复现已知 CVE 场景（如 CVE-2025-54136 的配置覆写链），并对至少 2 个真实商用编码助手给出可复现的差异化结论。

•资源：3—5 人（2 名安全研究、2 名开发、1 名产品/标准），无特殊硬件需求。

8.3 阶段二（3—6 个月）：横向扩展，建立基线

•扩展至 Ⅰ 类（编排式）与 Ⅲ 类（自主型），补齐 OS 级采集与长程轨迹评估能力；

•建立行业基准题库与首个失效模式库，实现跨对象可比——这是从「能测」到「能横评」的关键跃迁；

•完成与国内标准的条款映射（《智能体应用安全基本要求》八项技术要求、AIIA/T 0312-2026 九维度），输出合规视图；

•资源：扩展至 8—12 人，需 GPU 资源用于长程评估与裁判模型部署。

8.4 阶段三（6—12 个月）：闭环打通，工程化

•实现 CI/CD 门禁集成与运行时策略回灌，使评估从「项目制」转为「服务制」；

•扩展至 Ⅳ 类（多智能体）与 Ⅴ 类（具身/物理，须引入功能安全团队）；

•支撑 ISO/IEC 42001 认证所需的证据自动生成（对应第 9 章的权利映射表）；

•对外发布首个行业基准报告，建立平台的话语权与公信力。

8.5 阶段四（12—24 个月）：生态化与前瞻能力

•推动 OASP 协议开放与多厂商接入，形成「评估者—被测者—监管」三方互认生态；

•建设自主对抗智能体（autonomous red teaming）能力，与自主攻击对手持续对弈；

•提供持续性资格认证与漂移再认证服务，从「一次通过」转向「持续合规」。

8.6 组织与治理建议

第 9 章　合规对齐与证据映射

9.1 一次评估、多框架输出

平台的合规价值不在于「生成一份合规文档」，而在于「让一次评估活动的自然产出同时满足多个框架的要求」。这是通过映射关系而非重复劳动实现的。

重要提示：ISO/IEC 42001 的第二阶段审计不审查文档，而是抽样验证「策略是否在真实系统上、在审计期内被实际执行」。正如相关实践指南所指出：审计师要求的证据（运行时的策略决策日志、工具授权与撤回历史、按次运行的数据来源追溯、事件到具体智能体运行的溯源）几乎全部是运行时产生、事后无法重建的记录。这正是本平台「证据内生」设计原则的商业价值所在——评估平台在完成测评的同时，顺带产出了认证所需的证据集。

9.2 分阶段合规准备

第 10 章　前瞻研判与持续演进

10.1 三大前瞻方向

图 7　平台蓝图：以 OASP 开放智能体安全协议为内核的能力生态

10.1.1 从「人工红队」到「自主对抗智能体」

这是未来 12—24 个月最关键的能力代差。MITRE ATLAS 在 2026 年已新增 Autonomous Reconnaissance（AML.T0116）、Autonomous Attack-Path Adaptation（AML.T0117）、Autonomous AI Agent Communication（AML.T0118）、Autonomous Attack Orchestration（AML.T0124）等技法，并同步将战术 AML.TA0001 从「AI Attack Staging」更名为「AI Attack Adaptation」——这一更名本身即说明：对手已从「攻击前准备」演进到「攻击中实时适配」。

这意味着评估平台面对的将不再是「固定的用例库」，而是「会学习的对手」。如果评估仍以静态用例集为核心资产，其有效期将以月为单位衰减。因此平台必须具备与自主对手持续对弈的能力：红队侧由自主智能体在预算内自主探索攻击路径，蓝队侧实时记录并泛化为新用例，形成对抗性共演化。这也是 DoomArena 等模块化红队平台所代表的工程方向。

ATLAS 案例 AML.CS0069（GTG-1002）提供了现实注脚：国家背景组织越狱 Claude Code 并接入扫描器、浏览器自动化与口令破解工具，对约 30 家组织实施间谍活动，其中智能体承担了约 80—90% 的活动量。当攻击方已经用智能体规模化作业时，防御方的评估若仍靠人工，代差将不可弥合。

10.1.2 评估者自身的安全

一个此前几乎无人讨论、但必将成为刚需的问题：当评估平台大量使用模型裁判与红队智能体时，这些评估组件本身成为攻击目标。可能的攻击面包括：

•裁判投毒：被测对象在轨迹中植入特定模式，诱导裁判给出高分（类似「评分欺骗」）；

•目标劫持：红队智能体被被测系统的防御机制反向诱导，偏离攻击目标（「红队被策反」）；

•资源耗尽：被测对象通过构造超长轨迹使评估成本爆炸，实现「拒绝评估」（在经济学上等价于拒绝服务）；

•证据污染：攻击者篡改评估日志，使违规行为不被检出或使合规行为被误报。

应对原则：裁判隔离 + 结论交叉验证 + 人工仲裁兜底 + 证据链不可抵赖（签名与时间戳）。其中「评估者的可审计性」最为关键——评估平台的每一次裁决都应可被第三方复核，这也是 OASP 协议中「证据格式标准化」存在的根本理由。

10.1.3 从「一次通过」到「持续合规」：动态资格与漂移再认证

当前所有智能体安全评估都隐含一个错误假设：被测对象是静态的。实际上，智能体会持续变化——模型版本更新、工具增删、记忆累积、提示词调整、外部环境改变。任何一次变更都可能使先前的评估结论失效。

因此「通过认证」不应是终态，而应是「持续满足条件」的进行时。可预期的演进方向是动态资格体系：

•建立行为基线与漂移监测，将 ATLAS AML.M0038 的 Scope Drift Detection 要求落地为常态化能力；

•变更触发式再评估：工具增删、模型升级、权限变更自动触发对应维度的回归评估；

•资格动态降级机制：漂移超阈值时自动下调安全等级并触发人工复核，而非等到事故发生；

•对外提供「持续合规状态」（而非静态证书），类似金融行业的持续 KYC 模型。

这一演进的意义超出技术范畴：它将智能体安全从「合规成本」转变为「动态信任基础设施」。正如《智能助手类智能体安全分级规范与建设指南》所主张的——安全不再是智能助手的「成本项」，而是构建用户信任、形成差异化竞争力的核心资产。

10.2 结论

回到本报告开篇的问题：如何构建一个能够评估「不同类型的智能体」的安全评估平台？本报告给出的答案是三句话：

第一，分类是一切的前提。用「自主性 × 环境耦合度」划分五类，用九维权重矩阵决定测什么、测多深、门槛多严。类型失配是当前测评有效性的最大杀手。

第二，评估的对象是行动链，不是输出文本。所有可溯源的严重事件（EchoLeak、MCPoison、mcp-remote RCE、GTG-1002）都通过「模型被接入什么」实现，而非模型本身的缺陷。评估必须深入工具、凭据、配置、传输与沙箱。

第三，评估必须闭环且证据内生。结论要能回灌为运行时策略、进入 CI/CD 门禁、直接满足审计取证要求。测完即结束的评估，无论方法多先进，都无法转化为真实的安全能力。

展望：智能体安全评估正在从「安全测试的一个分支」演变为「AI 时代的基础信任设施」。当自主智能体承担企业 80% 以上的作业量时，决定其能否被托付关键任务的，不是模型评测榜单上的分数，而是可验证、可追溯、可持续的第三方安全评估能力。建设这一能力，既是安全团队的职责，也是企业在智能体时代获得竞争位势的战略投资。

附录 A　主要参考来源

本报告所有事实性数据均标注来源，供复核。以下为引用来源清单：

说明：本报告引用的厂商与产品名称仅用于技术说明与案例溯源，不构成推荐或评价；报告保持厂商中立视角。所有量化数据均来自上述公开来源，其中部分基准数据来自学术论文与安全厂商研究，不同测试条件与方法论下结果可能存在差异，实际应用中应以针对目标对象的实测结果为准。