信通院发布智能体安全评测基准V1.0：覆盖45个攻击场景，企业选型如何对照使用？

【软盟资讯·新闻导读】中国信息通信研究院发布《智能体安全评测基准V1.0》，覆盖45个攻击场景。对企业而言，这不只是新增一份测试清单，更重要的是把智能体安全从“功能能否实现”推进到“在攻击和误用条件下能否被控制”，为AI选型、合规审查和上线前自检提供了更统一的参照。

这项基准解决的，不只是“测不测安全”

企业过去开展AI安全评估，通常会沿用网络安全、数据安全和应用安全的方法：检查访问控制、漏洞扫描、日志留存、数据脱敏和合规制度。这些工作仍然必要，但智能体带来了新的复杂性。

传统应用往往按照预设流程执行，智能体则可能根据自然语言理解任务、调用外部工具、访问企业知识库、生成代码或触发业务流程。风险不只来自系统漏洞，也可能来自一条恶意指令、一个权限配置错误、一次不受约束的工具调用，甚至是模型对上下文的错误理解。

因此，智能体安全评估需要回答一组更具体的问题：

• 模型能否识别并拒绝恶意或越权指令？
• 智能体是否会被诱导泄露系统提示词、内部知识或敏感数据？
• 工具调用是否受到身份、权限、参数和频率限制？
• 智能体在多轮对话、复杂任务和异常输入下，能否保持安全边界？
• 当模型判断错误时，企业是否能够发现、阻断和追责？

《智能体安全评测基准V1.0》以45个攻击场景作为评测范围，价值在于将这些风险从抽象原则转化为可执行的测试任务。它并不意味着“通过评测就绝对安全”，但有助于企业减少各自定义测试口径造成的比较困难。

45个攻击场景，企业应如何理解

目前企业不宜简单把“45个场景”理解成45个独立漏洞，也不应只看供应商最终给出的一个总分。对采购和合规人员来说，更重要的是理解这些场景背后的风险链条。

从企业使用角度，可以将攻击场景映射到以下几类安全问题。这里是便于采购管理的分析框架，不等同于基准文件的官方分类。

一是模型与指令层风险

包括提示注入、越权指令、恶意上下文干扰以及多轮对话中的安全边界失效。攻击者可能通过直接指令，也可能借助文档、网页、邮件或知识库内容影响智能体判断。

这类测试重点不应只是看模型是否拒绝某一句话，而要观察它在上下文变化、任务拆解和连续交互中的行为是否稳定。一次成功拒绝并不能代表在改写表达、增加诱导条件后仍然有效。

二是数据与隐私层风险

企业需要关注智能体是否会泄露训练外数据、上下文内容、系统提示词、内部文档或其他用户信息。尤其当智能体连接企业知识库、客服记录、合同资料和研发文档时，数据边界可能比普通聊天应用更加复杂。

采购时应要求供应商说明测试数据范围、敏感信息类型、脱敏方式，以及评测是否覆盖跨会话、跨用户和跨权限的数据隔离。

三是工具调用与权限层风险

智能体真正进入业务系统后，风险往往不止于“说错话”，而在于“做错事”。如果它可以调用搜索、数据库、邮件、代码执行、支付、工单或审批工具，就必须验证调用权限、参数校验、人工确认和异常中止机制。

企业需要特别区分两种能力：智能体能否完成任务，以及它是否只能在授权范围内完成任务。前者体现效率，后者决定风险边界。

四是流程与任务执行层风险

智能体可能在任务拆解、记忆管理、循环执行和异常恢复过程中产生风险。例如，错误判断被不断放大，任务没有终止条件，或者多个智能体之间出现权限传递和责任不清。

这类场景提醒企业，评测对象不能只有基础模型，还应覆盖智能体编排框架、插件、工作流、记忆模块和外围业务系统。

五是运营与治理层风险

安全评测还应落到日志、告警、审计、人工接管和事件响应上。即使无法在所有情况下提前阻断，企业也需要知道：风险发生后能否定位原因，能否还原调用链，能否暂停相关权限，能否完成后续整改。

这也是智能体安全与一般模型能力测试的重要区别。企业最终采购的不是一段模型输出，而是一套能够持续运行、持续被管理的业务系统。

评测结果如何纳入企业AI选型

企业可以把基准作为供应商筛选中的“安全证据层”，但不要将其替代完整的尽职调查。建议按照“供应商材料审查—场景化复测—上线前验收—持续监控”四个阶段使用。

供应商材料审查：先看测试边界

采购团队首先要确认供应商提交的评测结果是否完整，包括：

• 被测对象是基础模型、智能体产品，还是包含工具和业务系统的完整方案；
• 覆盖了哪些攻击场景，哪些场景未纳入测试；
• 测试环境、模型版本、插件配置和权限设置是什么；
• 结果是单次测试、平均结果，还是经过多轮复测；
• 是否记录误报、漏报、拒答质量和业务可用性；
• 是否有第三方评测、内部测试和客户现场测试的区分。

如果只给出一个“通过”或“安全等级”，但没有测试条件和原始证据，企业很难判断其结果能否迁移到自身业务环境。

场景化复测：用自己的数据和流程验证

通用基准能够提供共同语言，但企业的风险通常与行业和流程直接相关。金融、医疗、制造、政务和营销场景所连接的数据、工具与审批机制不同，攻击面也不同。

企业可以从自身业务中挑选高风险任务进行复测，例如：

• 能否访问不属于当前岗位的数据；
• 能否绕过人工审批直接执行高风险操作；
• 能否被外部网页或上传文件中的指令诱导；
• 能否在多轮对话中泄露前序用户信息；
• 能否对数据库、代码或业务接口发起超出授权范围的调用；
• 出现异常时，能否及时停止并保留完整审计记录。

复测时应保留输入、输出、工具调用、权限状态和系统日志，避免只截取一段对话作为结论。

上线前验收：把安全要求写进合同和流程

对于高风险智能体，安全指标不应停留在技术交流材料中，而应进入采购合同、验收标准和服务等级协议。企业可以明确：

• 必须覆盖的攻击场景和最低通过要求；
• 重大风险的修复时限和复测机制；
• 模型、插件或提示词发生重大变更时的重新评估条件；
• 数据使用、日志留存、分权管理和人工接管要求；
• 安全事件通报、责任划分和退出机制。

需要注意的是，不能只设置“拒答率”这类单一指标。过度拒答可能降低风险，却也会让业务无法使用。更合理的验收应同时看安全性、准确性、可解释性、可控性和业务连续性。

持续运营：评测不是一次性证书

智能体的风险会随着模型升级、知识库变化、工具增加、权限调整和业务流程变更而变化。一次上线前测试不能覆盖整个生命周期。

企业至少应建立定期复测、变更触发复测、异常样本回放和权限审计机制，并为高风险操作设置人工确认、额度限制和紧急停用能力。对于能够自主执行任务的智能体，还应明确责任主体，避免出现“模型做的决定无人负责”。

企业采购与合规检查清单

在将评测基准用于AI选型时，可以用以下清单进行初步筛查：

评测对象

• [ ] 是否明确被测模型、智能体版本和部署形态；
• [ ] 是否包含实际使用的工具、插件、知识库和业务接口；
• [ ] 是否说明测试时间、环境和配置变化；
• [ ] 是否区分供应商自测、第三方评测和企业现场复测。

攻击场景

• [ ] 是否覆盖指令注入、数据泄露、权限越界和工具滥用等核心风险；
• [ ] 是否包含多轮对话、复杂任务和异常输入；
• [ ] 是否测试不同角色、不同权限和不同数据范围；
• [ ] 是否记录成功攻击、误报、漏报及修复后的复测结果。

防护与运营

• [ ] 是否具备工具调用前的身份和权限校验；
• [ ] 是否支持高风险操作的人机协同和人工中止；
• [ ] 是否保留输入、输出、调用链和审计日志；
• [ ] 是否提供安全事件响应、版本变更和漏洞修复机制。

合规与责任

• [ ] 数据处理范围、保存期限和跨境安排是否明确；
• [ ] 供应商是否允许企业开展现场验证和独立复测；
• [ ] 合同是否写明安全指标、整改时限和责任边界；
• [ ] 是否建立上线后的持续监测和退出预案。

使用基准时的三个风险提示

第一，不要把标准化评测等同于绝对安全。基准解决的是测试口径和风险识别问题，不能替代企业自身的威胁建模、权限治理和业务验收。

第二，不要只看场景数量和总分。45个攻击场景的覆盖广度有参考价值，但企业更应关注与自身业务直接相关的场景、测试深度和实际防护效果。

第三，不要忽视系统集成风险。模型本身表现良好，并不代表接入知识库、办公系统、代码仓库和外部工具后仍然安全。智能体的最终风险，取决于模型、数据、工具、权限和流程共同形成的系统边界。

【软盟观察】

智能体安全正在从“模型有没有风险”转向“企业能否把风险关在可管理的边界内”。信通院发布评测基准的意义，在于为供应商、采购方和监管关注者提供了更接近实际应用的共同参照，也让安全要求有机会从概念描述进入测试、验收和合同管理。

对企业而言，真正的机会不是借助一个标准快速完成“合规打勾”，而是把评测结果变成AI选型中的硬证据：看清供应商测了什么、没有测什么，确认结果能否适用于自己的数据和流程，再通过权限控制、人工接管和持续复测形成闭环。

需要保持的冷静判断是，智能体安全不会因为一份基准发布就自动解决。企业仍要承担场景定义、权限配置和上线治理责任。能够把通用评测与自身业务复测结合起来的企业，才更可能在获得AI效率的同时，把不可控风险降到可接受范围内。