當企業將 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 相關的倉庫中，並提供了多個工作領域的示例。對開發團隊來說，最有用的啟發或許不是直接照搬那組百分比數據，而是改掉「發現問題後只修改提示語、然後憑感覺上線」的習慣。應該先明確越界行為發生在何處，再使用可審計的規則來限制相關行為，並用相同的測試來證明修復是否有效，同時確保正常任務沒有受到影響。這套閉環管理仍需要人來選擇風險和批准控制，但它將原本分散的安全承諾，推進到了可重複的工程證據階段。