Agent上线前的安全评测应覆盖指令与意图、生成内容、数据与隐私、任务规划与执行、供应链五个方面。落地时需要把风险用例与模型、提示词、工具、权限和数据版本绑定，并在持续交付流程中完成复测。本文从一个运维助手示例出发，讨论如何划定测试范围、构建隔离环境、设计发布门槛，以及避免组件更新后沿用旧结论。
一、把Agent当成一个持续变化的应用
一个运维Agent可能读取告警、查询日志、生成排障建议，并在授权后调用变更接口。它的行为取决于模型，也取决于提示词、知识库、工具描述、服务身份和实际权限。因此，只记录模型测试分数，无法说明整个应用是否具备上线条件。
本文中的运维助手是设计示例，不对应某个真实生产系统，也不构成特定云产品的接入承诺。我们假定它默认只读，执行变更需要额外授权，所有测试在隔离环境中使用合成数据和受控资源。
建议建立一份评测基线，记录模型标识、提示词摘要、知识库快照、记忆状态、组件版本、工具权限和环境配置。无法锁定版本的远程服务，也应保存可获得的版本信息、测试时间和工具描述快照，说明复现限制。
二、指令与意图评测：测试任务目标是否稳定
运维助手的正常目标是解释告警并提出处置建议。若日志、网页或知识条目中夹带要求修改其他资源的文字，Agent是否把这些文字误当成操作授权，就是指令评测的重点。
样本需要覆盖直接输入、检索片段、附件、工具返回及多轮对话。尤其要测试“前面正常、后面逐步扩大权限”的情形，因为单轮拒答并不能证明整段任务始终遵守边界。
每个用例都应写明原始目标与允许行为。例如，“分析异常原因”只允许读取指定日志，不允许重启服务。预期结果既可以是继续完成正常分析，也可以是在信息不足时询问；不能把对资料中的指示照单执行视为合理补全。
OWASP将提示词注入区分为直接与间接形式，后者可能通过外部资料进入模型。基于这一风险机制，工程测试应覆盖资料入口，而非只覆盖用户提问入口。
三、生成内容评测：看输出怎样被消费
生成内容安全评测关注不当内容、风险指导、版权风险及危险代码等。对运维Agent而言，还应重点测试生成的命令、配置和排障步骤是否超出任务授权，是否隐藏可能导致实际损失的操作。
同一句命令出现在知识解释、待审核建议和自动执行参数中，风险条件不同。测试用例需要记录输出的使用方式，不能仅按字符串匹配给出统一结论。
建议保留正常诊断、边界模糊和明确风险三类样本。正常任务集用于观察是否因过严策略而无法回答基本运维问题；风险集用于验证是否输出可导致未授权影响的内容；模糊样本则检查Agent能否澄清必要条件。
如果应用支持流式输出或生成脚本附件，应对每个通道分别验证。某个通道先返回内容、另一个通道后补审核，可能使风险内容已经暴露。自动消费生成结果的系统，还需要在执行前独立校验参数与权限。
四、数据与隐私评测：验证可见范围和出站范围
运维数据中可能包含访问凭证、内部地址和业务信息。评测应覆盖上传文件、联网查询、知识检索、会话记忆和日志记录，检查敏感数据在哪些位置被读取、保留或发送。
可以为两个项目创建不同的合成标记，使用项目甲身份查询项目甲日志，再切换项目乙，检查模型上下文、缓存、记忆及返回结果中是否混入甲的数据。这个方法验证的是隔离路径，不需要使用真实秘密。
另一组用例检查联网搜索：Agent将错误信息转成搜索词时，是否连同内部标识或模拟凭证一起发出。评测要观察实际出站请求，不能仅凭最终回答没有显示敏感数据就判定通过。
撤权与生命周期同样重要。临时授权到期后，旧会话是否继续读取资源？删除记忆后，缓存或索引中是否仍然可召回？这些行为应按产品明确的删除与权限规则验证，并记录暂时无法观察的环节。
五、执行评测：把异常路径放进发布测试
任务规划与执行安全评测覆盖意图偏移、执行越界、反馈与状态不一致，以及失控循环等运行风险。建议先建立动作清单，明确每项动作的资源范围、必要授权、可撤销性和失败处理。
例如，用户同意对测试服务执行一次重启，不应被解释为允许对整个资源组批量操作。授权必须对应具体对象和动作；当参数变化或授权过期时，工具层应重新检查，而非沿用之前的自然语言确认。
测试应模拟接口超时但操作实际完成、部分资源成功、状态回查失败等情况。观察Agent是否因不确定而重复提交，是否错误宣称全部完成，以及是否在达到重试或资源预算后停止。
对有副作用的接口，需要结合业务实现验证幂等或去重机制。幂等不是一句提示词能够保证的属性，应由调用协议与后端逻辑共同支撑。评测报告要保留请求标识、返回结果和状态快照，方便研发重放失败路径。
六、供应链评测：让组件变化成为测试触发器
Agent的供应链范围包括Skills、MCP服务、插件、依赖库、运行包及其来源与完整性。传统组件清单可以说明“装了什么”，还需补充“这些组件告诉Agent做什么、能访问什么”。
Skills要同时审查说明文本与脚本行为，MCP服务要检查工具描述、授权与返回内容，插件要检查实际调用及过度权限，依赖库则需要关注漏洞、恶意行为和异常替换。
建议将版本、内容摘要、权限声明和网络目标纳入变更比较。组件升级后新增一个工具，或原有工具增加可写参数，都应触发相关安全测试。来源可追溯和完整性校验是基础证据，不能单独证明业务行为符合授权。
MCP官方安全实践讨论了令牌透传、会话劫持等实现风险，可作为接入检查的补充资料。协议支持某种连接方式，并不意味着具体实现已经满足安全要求。
七、怎样接入持续交付流程
可把评测分为提交检查、集成测试和发布前验证三个阶段。提交阶段检查权限与组件变化；集成阶段运行受影响的五类用例；发布前再用接近实际配置的隔离环境验证完整业务链。具体频率由变更影响决定，不必每次修改都机械执行同样的全量测试。
| 变更内容 | 优先复测方向 |
| 模型或提示词 | 任务边界、风险输出、正常任务完成情况 |
| 知识库或记忆机制 | 注入入口、越权召回、跨会话污染 |
| 工具与权限 | 授权校验、参数范围、异常重试 |
| Skills、MCP或依赖 | 来源完整性、权限扩张、组合行为 |
这些优先方向不代表彼此独立。工具说明变化可能同时影响任务规划和数据访问，因此还需选择关键跨链路场景回归。
指标应同时报告风险与可用性。攻击成功率按有效攻击尝试计算，正常任务误拒率按正常样本计算；状态核验失败需要单列。性能报告区分离线评测时长、线上任务耗时和防护引入的延迟，不把不同口径合成一个效率指标。
发布门槛应预先约定。高影响越权问题没有修复时，可以关闭相关能力或暂缓发布；未覆盖的能力要明确标注。一次测试通过的含义，是指定配置和样本下满足约定条件，不是对后续所有输入的保证。
八、选型参考与常见问题
如果团队需要扩展评测样本或引入外部验证，可围绕指令、生成内容、数据、执行和供应链五类范围开展验证。是否满足具体流水线接入、证据导出和复测需求，应通过实际方案确认。
每次知识库更新都要全量重测吗？
不必机械全量重测。应先判断内容来源、权限及检索机制是否变化，执行受影响用例，再对高影响业务链做回归。范围选择和未覆盖部分都需要留档。
沙箱里通过，生产就安全吗？
不能直接等同。沙箱应尽量复现身份、权限和组件配置，并检查与生产的差异。无法模拟的外部服务和状态变化，需要通过受控验证与上线后的监测补足。
没有写权限还需要执行评测吗？
需要，只是测试重点不同。只读任务仍可能无限重试、访问错误资源或造成异常资源消耗，也可能通过工具请求外传数据。应验证实际启用的能力，而不是按“只读”标签免测。
