1. Scope and Problem Statement
Legacy Data Loss Prevention (DLP) solutions rely on centralized cloud proxies that intercept traffic between enterprise clients and Large Language Model (LLM) APIs. Under European Union GDPR Article 28, this intermediary processing designates the DLP vendor as a formal Data Processor, requiring extensive Data Processing Agreements (DPA), vendor risk audits, and recurring egress latency penalties of 150ms to 300ms.
Furthermore, sensitive data ingested into Retrieval-Augmented Generation (RAG) vector embeddings violates GDPR Article 17 (Right to be Forgotten), as high-dimensional vector representations cannot be excised without full database re-indexing. ZTDS solves this by enforcing in-memory client-side data de-identification prior to network transmission.
2. The 4 Non-Negotiable Invariants
Invariant 1: Volatile Memory Scoping (RAM-Only)
All mapping pairs between sensitive entities and non-informative tokens (e.g. {"[NAME_1]": "John Doe"}) MUST be held strictly in volatile RAM. Persisting session maps to cookies, localStorage, IndexedDB, or swap space constitutes a compliance violation. In web browsers, maps must be isolated per tab ID.
Invariant 2: Sub-2ms Latency Budget
Deterministic parsing, regex heuristic matching, and token replacement MUST execute within a maximum budget of 2 milliseconds per 15,000-character payload on standard consumer hardware.
Invariant 3: Zero Network Egress (Airplane Mode Test)
The sanitization engine MUST be capable of complete autonomous operation with all physical and wireless network adapters severed. Network packet inspection during sanitization must record exactly 0 bytes transmitted.
Invariant 4: Cryptographic Transport Security
Multi-user collaborative handoff of token maps must enforce client-side authenticated encryption using Argon2id (memory: 19 MiB, iterations: 2) for key derivation and XChaCha20-Poly1305 (256-bit key, 192-bit random nonce). Cleartext keys must never touch central relays.
3. Tokenization Taxonomy & Syntax
ZTDS standardizes structured bracketed tokens that preserve grammatical context while removing informational entropy:
[NAME_N]— Personal names, physician identifiers, executive titles[EMAIL_N]— Corporate and personal email addresses[PHONE_N]— Universal international and domestic telephone numbers[ID_N]— National IDs, SSN, Tax numbers, passport numbers[SECRET_N]— API keys, AWS credentials, JWT tokens, private certificates[FINANCIAL_N]— Credit card PANs, IBANs, bank routing numbers
To prevent LLM tokenization mutations (e.g. [NAME_1] translated or broken by BPE encoders), de-tokenizers must implement fuzzy token recovery regexes: /[\[\(\{<]NAME[ _-]?(\d+)[\]\}\)>]/gi.
4. Regulatory & GRC Cross-Mapping
| Framework | Article / Section | ZTDS Implementation |
|---|---|---|
| EU GDPR | Article 28 (DPA) | Exempt (0 server processing) |
| EU GDPR | Article 17 (Right to Erasure) | RAG vectors contain 0 cleartext PII |
| HIPAA | 45 CFR § 164.514(b) | Safe Harbor 18 PHI de-identification |
| SOC 2 Type II | CC6.7 (Data Transmission) | Eliminates unencrypted PII egress |
| EU AI Act | Article 50 (Transparency) | Cryptographic audit receipts generated |