Resolved by reference to existing guidance already covering this exact failure. Root cause: the filter's pattern was authored against decoded, human readable text but evaluated against the serialized wire form, where JSON escaping turns a single separator character into two characters. A rule that expects one separator followed by a non separator character cannot match the doubled form, so escaped paths pass through undetected, and the same escaping can also manufacture false positives in unrelated text. The fix is architectural rather than a smarter pattern: parse the payload with a strict, canonical parser, apply validation rules to the decoded scalar values rather than the serialized bytes, and have the filter itself emit the canonical re-serialized bytes it validated, so the caller cannot reintroduce a differential by re-serializing independently. Layer additional controls: declare a permitted shape per field before any heuristic runs, use a linear time pattern engine with no backreferences or lookaround since a positive allowlist does not by itself remove backtracking risk, reject invisible or default ignorable characters outright rather than trying to normalize them away, and score identifying shape per whitespace separated token rather than only at string boundaries, since a value embedded mid sentence defeats anchored signals. Bound all decoding and traversal work with one shared counted budget for bytes, depth, node count, and decode rounds, enforced during the walk rather than after it. Default the verdict to deny and only assign allow as the final step of a clean pass, mapping any internal error to deny at the boundary, and withhold the entire document on any abort rather than sharing a partially scanned prefix, since a partial share turns a resource limit into a disclosure channel. For telemetry, record only a schema field pointer, a rule identifier drawn from a closed enumeration, and a keyed hash under a rotating secret for correlation, never the rejected value, and bucket any counts coarsely since an exact length or character histogram itself carries enough information to reconstruct the value. One correction worth keeping: an escape that is introduced by the very separator character it encodes still contains that character in the raw bytes, so a byte level scan for the character still fires in that case; the genuine evasion cases are encodings whose escape form does not literally contain the target byte, such as percent encoding, base64, or markup entities, not backslash pair escaping of the separator itself. This is reasoned design analysis and adversarial review, not a report of executed tests; recommended validation is an adversarial corpus asserting a planted marker never reaches logs, metrics, traces, or error text across every abort path, plus a one sided property that no encoding of a value that would be denied in raw form is allowed.

A privacy filter scans outgoing JSON payloads for values that look like filesystem paths, using a regex tuned for ordinary unescaped text. When a path is embedded inside a JSON string, its separator characters can appear in an escaped form. A regex written against the plain-text form of the path may no longer match the escaped serialized form, so a real path can pass the filter undetected. The core question is how to validate structured string values inside JSON robustly against this class of evasion, operating on decoded or canonicalized values rather than on raw serialized text, while never logging or persisting the rejected content itself, since logging a raw rejected value would recreate the very leak the filter exists to prevent. Known evidence: JSON escaping changes how separator and drive-letter style substrings appear in the raw text stream, so text-level regexes are brittle against structurally encoded data. Open questions: what decode-then-normalize validation approach achieves reliable detection with low false positives, and what can safely be recorded for audit purposes (counts, categories, hashes) without ever emitting the offending value.