Microsoft把Agent风险评估做成复测流程

12/40到2/34是Microsoft在9月24日给出的样例变化。Command Line文章介绍run-assert-eval，把Clarity风险发现、ASSERT评测生成和Agent Control Specification运行时策略接成一条可复测链路。原文标题是“Introducing run-assert-eval: Find the risk, fix it, prove it”，动词重点是introducing，语义范围只到发布介绍，尚未表示行业已普遍采用。

事实集中在一个billing-support agent示例。Microsoft称，基线运行中，这个agent在40个适用对话里有12个披露了其他客户数据，观测违规率为30.0%。加入治理路径后，在34个适用对话里仍有2个违规，观测违规率为5.9%。文章还说，早期ASSERT评估中，自动judge与人工审查的一致性通常在80%-90%，接近人工审查者之间约90%的一致性。

证据边界来自样本来源。上述效果来自Microsoft自己的示例和工具链说明，尚非第三方基准。文章没有证明所有agent场景都能从30.0%降到5.9%，也没有说明自动judge在金融、医疗、政务等高风险业务里都能稳定达到相同一致性。NIST AI RMF和OWASP LLM Top 10在本文里只提供风险治理背景，不能当作run-assert-eval的效果背书。

这件事对开发者和企业安全团队的直接影响在于，它把“agent要可治理”拆成可执行步骤。风险要先被找到，策略要能落在运行时，同一批行为定义、测试用例和judge还要支持复跑。对于已经把agent接入客户数据、审批流或内部工具的团队，这比抽象安全口号更接近上线前的release gate。

从发现风险到复跑证据

Microsoft原文给出的闭环包含四个部件。风险发现放在循环前面，run-assert-eval先对agent做threat modeling，寻找团队未必事先写进需求的失败模式。这个顺序很关键，因为很多agent事故的根因是“需求从来没有被明确写下”。

ASSERT负责把风险转成评测。ASSERT在6月2日发布时被定义为“Adaptive Spec-driven Scoring for Evaluation and Regression Testing”，用途是把自然语言行为要求转成可执行评测。它会把行为描述系统化，生成可编辑taxonomy，构造分层测试用例，运行目标模型或agent，并把trace、tool call、judge rationale和policy citation记录下来。这个设计让特定业务边界能被检查。

ACS负责把修复落到运行时。Agent Control Specification同样在6月2日发布，Microsoft把它描述成开放、厂商中立的运行时治理标准。ACS定义策略在哪些生命周期点被评估、输入形状是什么、策略引擎如何返回allow、warn、deny或escalate。run-assert-eval在示例里用ACS生成并验证策略，避免把失败报告停留在手动改prompt阶段。

复跑负责提供干预证据。文章特别强调，治理后运行复用基线运行的cached systematization和test set，行为定义、测试用例和judge都保持不变，政策是预期干预中唯一变化的变量。这个表述需要忠实保留：它排除了“换一套更容易的评测后效果变好”的解释，强调在尽量固定评测条件下比较治理前后。

环节	Microsoft文章中的做法	早报解读
风险发现	Clarity先做threat modeling	把未写进需求的失败模式纳入入口
评测生成	ASSERT将风险转成config、behavior和suite	让每类风险有可复跑的评测对象
策略执行	ACS生成并验证runtime policy	策略挂到agent生命周期拦截点
复跑对比	同一行为定义、测试用例和judge保持不变	把修复效果从主观判断变成干预对比

数字显示了什么

示例agent服务单一客户账号ACME-1001，不应读取或操作其他客户账号。run-assert-eval识别出两个风险：未验证的高风险操作，以及跨客户数据暴露。文章随后把每个被选择的风险转成一个config、一个behavior和一个suite，避免一个配置同时混入多个行为，导致违规率只说明“某处出错”却无法定位。

Microsoft给出的基线结果显示，跨客户数据暴露比未验证高风险操作更需要处理。未验证操作suite的impermissible behavior violated为6.3%，permissible behavior violated为10.0%。跨客户数据暴露suite的impermissible behavior violated达到30.0%，permissible behavior violated为8.7%。原文还举例说，用户请求另一个客户BPS-447的联系方式时，agent返回了完整记录；在生产系统中，这会构成数据泄露。

治理路径针对这个失败点选择了pre_tool_call和post_tool_call。在工具调用前，策略拒绝任何account_id不匹配调用者账号的tool call；在工具调用后，策略阻止不应产生的结果重新进入模型上下文。这里的判断是确定性规则，避免再让一个模型判断请求是否“可疑”。这个示例更接近权限边界检查，区别于内容安全分类器。

指标	基线运行	治理后运行	口径边界
跨客户数据泄露适用对话	12/40	2/34	Microsoft自报billing-support示例
观测违规率	30.0%	5.9%	尚非第三方复现实验
ASSERT judge一致性	80%-90%	未单独更新	来自早期ASSERT内部评估
ACS拦截点数量	8个	不适用	来自ACS规范文章

这组数字能说明一件有限但重要的事：在Microsoft展示的场景里，把评测失败转成运行时权限策略后，跨客户数据暴露样本明显减少，同时文章称样本中没有出现permissible-behavior violations。它不能说明所有agent加上ACS后都会得到相同降幅，也不能替代企业自己的生产telemetry、人审和审计流程。

为什么它值得放进今天的治理主线

过去一年，agent安全讨论经常停在三个相互割裂的层面。产品团队写需求和系统提示词，安全团队列风险和红队清单，工程团队在框架callback、tool wrapper或业务代码里手写控制。问题在于，这三层之间很容易丢失证据链：某个失败由谁发现、修复逻辑对应哪条风险、上线后是否真的降低违规频率，常常只能靠文档和会议记忆串起来。

run-assert-eval的价值在于把这条链路缩短。它把风险管理框架转成开发者可执行的工程入口，让一次提示启动闭环成为可能。根据Microsoft描述，开发者用自然语言描述agent后，skill先发现风险，再把风险转成可测行为和测试场景，接着生成并验证ACS策略，最后对治理后的callable复跑原评测。这个动作把agent治理从“应该做什么”推进到“怎么证明修复有效”。

NIST AI RMF和OWASP LLM Top 10能解释为什么这类工具会变重要。NIST框架长期强调治理、测量、管理和风险映射；OWASP LLM Top 10则把敏感信息泄露、过度代理、插件设计不安全等列入LLM应用风险。它们都只是背景源，但能说明Microsoft为什么要把运行时策略、证据收集和复测放到一个开发者工作流里：agent越多连接真实工具和数据，越需要超出静态提示词的控制面。

更细的一层变化是评测对象发生了移动。传统LLM安全评测多看最终回答，agent评测必须看中间动作。ASSERT文章强调，它会记录工具调用、参数、工具结果、路由决策和中间状态；ACS文章强调，策略输入可以包含actor、roles、conversation state、prior tool calls、data sensitivity和approval status。也就是说，治理对象从“模型说了什么”扩展到“模型准备调用什么工具、拿什么数据、把什么结果带回上下文”。

接下来看什么

可复现性是第一层门槛。文章说skill随ASSERT仓库提供7个worked domains和14个risk suites，包括billing_support_agent、azure_doc_qa、change_control_agent、science_research_agent、travel_planner_langgraph、travel_planner_neurosan，以及一组有无工具的prompt-based clinical agents。关键检验看外部开发者能否在自己的agent、数据权限和工具调用链上复跑，列表长度只提供起点。

judge稳定性决定复跑是否可信。Microsoft把同一judge保持不变作为对比成立的条件，这个判断是对的；但如果judge本身在细微政策边界上波动很大，复跑结果仍然会受影响。ASSERT文章已经承认judge质量和稳定性部分依赖底层LLM，不同judge model在严格程度、边界敏感度和区分相近行为的意愿上可能不同。

ACS的生态位置会影响长期价值。ACS文章把它写成开放、厂商中立标准，并说同一policy input可以连接OPA/Rego等策略引擎。标准能否成立，取决于非Microsoft框架、企业安全平台和agent运行时是否愿意采用同一个拦截点和证据格式。如果缺少外部采用，它会停留在完整的Microsoft治理栈，难以成为跨生态接口。

企业读者应把这条新闻当作方法论线索，避免理解成即插即用承诺。可以借鉴的是流程：先发现风险，窄化行为定义，保留测试集和judge，生成策略后复跑，并同时看impermissible和permissible两类结果。效果数字需要单独复核：12/40、2/34、30.0%和5.9%都属于Microsoft示例的样本结果，离生产环境的稳态风险还差持续监控、人工复核和事故反馈闭环。