隐私过滤器，也需要检查指令是否被改写

zkAPI 的2026年10月16日本地评估观察到约束被改写的情况；作者声明，结果不能证明匿名性或语义等价。评估记录

这给在远端模型前加入本地编辑器的团队提出了一个实际问题：谁来确认，改写后的请求仍然保留相同的授权？下文是 Open Market Notes 提出的测试方法，并非已部署系统的实测结果。

检查决策，不只看句子是否通顺

建立成对的纯虚构任务。其中一个允许采购助手准备供应商订单；另一个允许它在指定角色批准后提交订单。两者的商业细节保持一致。文本进入过滤器前，评审者先记录允许的最终行动。改写之后，再盲评行动边界，不让评审者知道文本来自哪个版本。

这比判断两段话是否“大致一个意思”更严格。一份简洁的摘要可能保留了主题，却删去了下一步必须由谁批准。即使订单其他内容完全正确，这也应被记为失败。

身份信息减少，要单独计分

Tor 的官方指南提醒，向目标网站提供个人信息，可能让网站识别用户。这是通用浏览器指南，不是对 zkAPI 的验证。Tor 指南

在我们提出的测试中，可以虚构一份客户资料，其中包含与任务无关的细节，同时设置一个完成任务所必需的审批角色。分别评价前者是否被移除、后者是否被保留。单一总分可能掩盖一种情况：过滤器删掉了几乎所有信息，连正确行动所需的信息也没有留下。

检查完整的传递过程

该分支文档说明，工具返回内容和附件保持不变。文档

把虚构发票作为第二条输入渠道，在其中放入无害的唯一标记，再通过经过批准的测试记录工具检查组装完成的外发请求。这样检验的是实际传递过程，而不是从改写后的聊天消息推断请求内容。整个过程不需要真实客户数据。

让失败可以回退

我们建议设置一道发布门槛：权限检查失败时，阻止改写请求进入能够执行行动的代理。原始任务留在本地，供有权限的人复核，不应静默回退到向外发送原文。过滤器、模型或消息组装方式变化后，都应重新测试。

这些是建议的控制措施，并非已经测得的保证。采购时值得追问的是：供应商能否复现一次权限保留失败，并展示系统随后会停止什么。