隱私過濾器，也需要檢查指令是否被改寫

zkAPI 的2026年10月16日本地評估觀察到約束被改寫的情況；作者聲明，結果不能證明匿名性或語義等價。評估紀錄

這給在遠端模型前加入本地編輯器的團隊提出了一個實際問題：誰來確認，改寫後的請求仍然保留相同的授權？下文是 Open Market Notes 提出的測試方法，並非已部署系統的實測結果。

檢查決策，不只看句子是否通順

建立成對的純虛構任務。其中一個允許採購助手準備供應商訂單；另一個允許它在指定角色批准後提交訂單。兩者的商業細節保持一致。文字進入過濾器前，評審者先記錄允許的最終行動。改寫之後，再盲評行動邊界，不讓評審者知道文字來自哪個版本。

這比判斷兩段話是否「大致一個意思」更嚴格。一份簡潔的摘要可能保留了主題，卻刪去了下一步必須由誰批准。即使訂單其他內容完全正確，這也應被記為失敗。

身分資訊減少，要單獨計分

Tor 的官方指南提醒，向目標網站提供個人資訊，可能讓網站識別使用者。這是通用瀏覽器指南，不是對 zkAPI 的驗證。Tor 指南

在我們提出的測試中，可以虛構一份客戶資料，其中包含與任務無關的細節，同時設定一個完成任務所必需的審批角色。分別評價前者是否被移除、後者是否被保留。單一總分可能掩蓋一種情況：過濾器刪掉了幾乎所有資訊，連正確行動所需的資訊也沒有留下。

檢查完整的傳遞過程

該分支文件說明，工具回傳內容和附件保持不變。文件

把虛構發票作為第二條輸入管道，在其中放入無害的唯一標記，再透過經過批准的測試記錄工具檢查組裝完成的外發請求。這樣檢驗的是實際傳遞過程，而不是從改寫後的聊天訊息推斷請求內容。整個過程不需要真實客戶資料。

讓失敗可以回退

我們建議設定一道發布門檻：權限檢查失敗時，阻止改寫請求進入能夠執行行動的代理。原始任務留在本地，供有權限的人覆核，不應靜默回退到向外傳送原文。過濾器、模型或訊息組裝方式變化後，都應重新測試。

這些是建議的控制措施，並非已經測得的保證。採購時值得追問的是：供應商能否重現一次權限保留失敗，並展示系統隨後會停止什麼。