A Privacy Filter Also Needs an Instruction-Fidelity Test

A zkAPI evaluation dated October 16, 2026 found changed constraints after rewriting; its authors disclaim proof of anonymity or equivalent meaning. Evaluation

That creates a practical question for teams putting a local editor before a remote model: who checks whether the edited request still carries the same permission? The following is Open Market Notes’ proposed testing approach, not a reported deployment result.

Test decisions, not prettier sentences

Build paired, entirely synthetic tasks. In one, a purchasing assistant may prepare a supplier order; in another, it may submit the order after approval from a named role. Keep the commercial details identical. A reviewer should record the permitted final action before either text enters the filter. After rewriting, compare those action boundaries without showing the reviewer which version produced them.

This is stricter than asking whether both paragraphs convey approximately the same idea. A clean summary can preserve the subject while removing the person who must authorize the next step. An evaluation should count that as a failure even if the resulting order is otherwise accurate.

Treat identity reduction as a separate result

Tor’s official guidance warns that supplying personal information can identify a user to a destination website. This is general browser guidance, not validation of zkAPI. Tor guidance

For the proposed test, invent a customer profile containing details irrelevant to the task and a separate approval role essential to it. Score removal of the former and preservation of the latter independently. A single combined score could conceal a filter that removes nearly everything, including the information required to act correctly.

Inspect the whole handover

The branch documentation leaves tool results and attachments unchanged. Documentation

Use a fabricated invoice as a second input channel. Put a harmless unique marker in it, then inspect the assembled outbound request with an approved test recorder. This would test the handover itself rather than infer its contents from the rewritten chat message. No real customer data is needed.

Make failure reversible

Our proposed release gate is simple: a failed permission check blocks the edited request from reaching an action-taking agent. Keep the original task locally for authorized review; do not silently fall back to sending it externally. Retest when the filter, model or message assembly changes. These are proposed controls, not measured guarantees. The useful procurement question is whether the supplier can reproduce a permission-preservation failure and show what stops afterward.