企业把AI代理接进客服、财务和内部系统时，最难的未必是让它回答得更快，而是弄清它会在什么场景下越界。微软9月24日介绍的开源技能run-assert-eval，把风险发现、测试、运行时限制和再次测试连成一条流程。其核心并非宣称“装上就安全”，而是要求开发团队留下前后可比的证据：同一批问题、同一种评判方式，修改前到底错了多少次，修改后又错了多少次。

微软给出的演示是一名账单客服代理。它本应只处理来电者自己的账户，却可能按照对话里的说辞，读取另一个客户的资料。这样的错误很难靠一条“不要泄露信息”的提示词彻底挡住，因为越界可能发生在调用工具、读取返回结果，或经过多轮对话后把账户范围悄悄扩大。更麻烦的是，产品需求文档未必事先列出了所有可能的失误；如果只按已有需求做测试，最危险的漏洞恰好会漏掉。

不是再做一张安全评分表，而是把发现、干预和复测接起来

这套流程首先让Clarity对代理做威胁建模，寻找原本没有写进需求的失败模式。它不是直接把一大堆风险交给模型自动裁决，而是将候选问题列出来，由人选定优先测试的项目。随后ASSERT把每一项风险收窄成可测量的行为，构造不同提问方式和业务情境：有人直接要别人的账户，有人声称自己受托管理，也有人在多轮交流中慢慢跨过权限边界。风险定义越清楚，测出的失误才越容易指向具体修复点。

微软特别强调两个指标要分开看。一项是代理做了不该做的事，例如透露别人的资料；另一项是代理拒绝了本应完成的合法请求。若安全防护让客服逢问必拒，第一项数字可能很好看，用户体验却已经失败。因此，前后对比不只记录违规率，也记录服务能力是否受损。这个设计听起来朴素，却击中了很多AI安全演示的软肋：只展示被拦住的恶意输入，却不展示正常工作是不是也被拦住了。

在这次账单案例中，微软报告，跨客户数据泄露在基线测试的40个适用会话中发生12次，即观察到30.0%。加入治理规则后，在34个适用会话中观察到2次，即5.9%。这些数字对应微软展示的样例与测试配置，不是所有企业代理的通用风险率，也不能被理解为“风险已经消失”。样本量、情境设置和自动评审都会影响结果。尤其需要注意的是，剩余的两次违规仍意味着代理或防护链还要继续改进。

这条链路中真正起约束作用的，是Agent Control Specification生成并供人审查的运行时策略。对于越权读取，策略被放在工具调用前的关口，检查请求中的account_id是否属于当前客户；调用后的关口还会复核返回结果，防止不该出现的数据流入模型上下文。这比只对聊天文本说“请谨慎”更明确：判断依据是账户标识能否匹配，拦截位置也贴近风险实际发生的接口。当然，生成出来的规则不是自动批准，策略、清单和接线位置仍需人工检查。

为什么“同卷复测”比一次漂亮的演示重要

模型评估最容易被忽视的陷阱，是修复前后用的不是同一把尺子。团队改完代理后重新生成题目、换一个评判模型，再拿新成绩和旧成绩相比，看似进步，实际上可能只是考试变容易了。微软的流程试图固定行为定义、测试案例和评判方式，把策略改动作为主要变量。演示中跨客户泄露的不同测试切分均有下降，但某些切分仍有违规；合法请求被错误拒绝的样例指标没有恶化。这个结果支持在该设定下继续探索，却不是生产环境零事故保证书。

另一层现实约束是适用范围。每家公司都得决定哪些资料算敏感、谁有权批准跨账户访问、工具参数可不可以被伪造，以及被拦截后怎样通知用户。一个精确的规则只能处理它看得见的字段；若上游身份验证本身不可靠，后端策略也无法凭空修正业务事实。评估集还应定期更新，以应对新功能、新工具和攻击方式，但每次版本对比又应保留稳定的基线，避免混淆变化原因。

微软把run-assert-eval作为开放技能放在ASSERT相关仓库，并给出多个工作域的示例。对开发团队最有用的启发，或许不是照搬那组百分比，而是改掉“发现问题以后只改提示词、然后凭感觉上线”的习惯。先明确越界发生在何处，再用可审计规则限制动作，用同样的测试证明修复是否有效，同时确认正常任务没有被误伤。这套闭环仍需人来选择风险和批准控制，但它把原先零散的安全承诺，往可重复的工程证据推进了一步。