1. Executive Summary & Scope
As commercial enterprises and consultancies increasingly adopt frontier AI endpoints (OpenAI ChatGPT, Anthropic Claude, Google Gemini), legal and compliance obligations under the European General Data Protection Regulation (GDPR) create acute operational friction. Transferring unmasked personal data, employee records, or citizen identifiers to commercial LLM APIs triggers strict Data Processing Agreement (DPA) sub-processor liabilities under GDPR Article 28 and severe re-identification penalties under GDPR Article 9.
To evaluate whether an on-device, in-browser tokenization engine can eliminate this liability without adding server infrastructure, Match2Market conducted an independent 90-minute hands-on evaluation of the Zero-Trust Data Sanitization (ZTDS) paradigm using the PrivacyScrubber reference implementation in an isolated Chrome browser profile with synthetic Dutch commercial datasets.
2. Evaluated Architecture & Key Strengths
The evaluation tested both the standalone web application and the Manifest V3 browser extension across synthetic prompts containing customer names, order numbers, national citizen codes, and commercial narrative briefs. Several architectural capabilities demonstrated immediate utility:
The Chrome extension directly intercepts the ChatGPT input DOM textarea, allowing users to visually inspect sanitized surrogate tokens ([NAME_1], [ID_1]) before the prompt is transmitted over the network socket.
Repeated identifiers throughout the input prompt maintain consistent token assignments across multi-turn reasoning, allowing the LLM to process relationships between entities without accessing cleartext PII.
When the AI returns a response containing surrogate tokens, the client-side session map rehydrates the original Dutch identifiers locally on screen without persisting tokens to cookies, localStorage, or remote servers.
Detected entities can be reviewed prior to submission, allowing users to immediately unmask non-sensitive false positives with a single click while leaving sensitive tokens protected.
3. Field Findings & Engineering Remediations
The value of hands-on validation lies in exposing boundary conditions that standard unit tests miss. During testing with synthetic Dutch prompts, Match2Market identified four specific areas of friction, which were subsequently analyzed and resolved by the ZTDS engineering team:
Finding: Labeled Dutch BSN test numbers remained visible under the General profile unless a custom user regex was added. While the custom regex worked seamlessly and persisted tokens correctly, universal protection required native detection.
Remediation: Added native regex pattern \b(?:BSN(?:-nummer)?|Burgerservicenummer|SOFI)[^\S\r\n]*[:#=-]?[^\S\r\n]*(\d{8,9})\b and KvK company registration detection to the baseline REGEX_RULES across Web, Extension, MCP, and SDK planes.
Finding: Standard European business nomenclature combining initials with noble particles (e.g., J. de Ruiter, P. van Gameren) failed to trigger name detection due to leading punctuation constraints.
Remediation: Implemented initial-prefixed lookahead regex (?:\p{Lu}\.(?:[ \t\xA0]*\p{Lu}\.)*)[ \t\xA0]+(?:(?:van|von|de|te|ten|ter|in 't)[ \t\xA0]+){0,2} and registered Dutch salutations (beste, geachte, mevrouw, dhr) in NOT_NAME_WORDS to avoid swallowing greetings into names.
Finding: When individual false positives were reverted and zero tokens remained in the prompt, the extension’s appended [Privacy Note: ...] instruction block remained attached to the prompt textarea.
Remediation: Updated base-injector.js to scan restoredText with token verification regex, automatically stripping the Privacy Note when the remaining token count reaches zero.
Finding: The PDF audit receipt generated by the tool makes robust compliance claims. The documentation needed to precisely delineate what client-side SHA-256 hashing establishes.
Remediation: Clarified in ZTDS RFC v1.0: the receipt mathematically proves local volatile RAM tokenization and session digest integrity; it verifies that the client performed zero-server de-identification prior to egress.
4. Regulatory Implications for European Enterprises
Under traditional Cloud DLP or gateway proxy architectures, sensitive employee prompts must be routed through a third-party intermediary server for inspection. This creates a secondary data processor under GDPR Article 28, requiring Data Processing Agreements, security attestations, and risk assessments.
By contrast, Zero-Trust Data Sanitization (ZTDS) operates completely inside the local V8 JavaScript engine of the user's browser or device RAM:
- 0 Outbound Bytes: No prompt data, tokens, or session maps are ever sent to PrivacyScrubber or ZTDS servers.
- DPA Exemption: Because no third-party server ever accesses the cleartext personal data, no sub-processor relationship is established.
- Airplane Mode Verified: The entire sanitization and reveal cycle functions seamlessly with the network interface disconnected.
5. Conclusion & Evaluator Statement
“I tested PrivacyScrubber in Chrome with synthetic Dutch prompts. The in-chat shield let me inspect a protected prompt before sending it, and repeated identifiers kept consistent tokens through the ChatGPT response. I particularly liked being able to reveal the original values on screen and restore individual false positives. Adding a custom rule for Dutch BSNs also worked well in my test. A promising, practical workflow for taking more control over what you share in AI chats.”