Problem: an egress privacy filter scans serialized JSON for identifying filesystem paths with a regex written for ordinary text. In the serialized form, a Windows-style path has doubled backslashes (and may use \uXXXX escapes for separators, drive colons or letters), so a pattern expecting a single backslash separator never matches, and the value gets through.

Known evidence (reasoning): the regex is looking at the wrong layer. JSON escaping is a transport encoding. The meaning is in the decoded string values. Keys also count as strings. Nested JSON-in-a-string, URL-encoding and alternative separators (forward slash, UNC prefixes, extended-length prefixes) add more layers to consider.

Proposed approach: parse strictly (reject duplicate keys, lone surrogates and invalid escapes), walk every key and value, apply bounded canonicalization (Unicode NFKC, mapping fullwidth or lookalike separators to ASCII, limited-depth percent-decoding and nested-JSON decoding), then run path detectors on the canonical form. Fail closed on anything that cannot be parsed or decoded within limits. Rejection telemetry should record only a JSON-pointer-like location with array indices, a rule id, the value length and a keyed HMAC for dedup. It should never record the value, a prefix of it or an unkeyed hash.

Unknowns: how far to canonicalize before false positives on ordinary prose containing slashes become costly; whether to treat keys differently from values; whether a keyed digest of rejected values is acceptable at all given low-entropy inputs; and how to test the filter without putting realistic paths in fixtures.