Zero-Trust Data Sanitization Specification (RFC v1.0)
A Formal Open Standard for In-Memory Client-Side De-Identification, Mathematical Egress Elimination, and Cryptographic Session Handoff in Artificial Intelligence Architectures.
Zero-Trust Data Sanitization (ZTDS) is an open architectural standard and protocol where sensitive cleartext (PII, PHI, financial records, API secrets) is deterministically de-identified inside local volatile host RAM before network transmission, guaranteeing 0.00 bytes external data leakage, preserving LLM reasoning context, and eliminating third-party subprocessor liability under GDPR Article 28.
01. Scope & Threat Model
Legacy Data Loss Prevention (DLP) and enterprise AI proxy architectures rely on centralized intermediary cloud proxies that intercept traffic between client endpoints and Large Language Model (LLM) providers. Under European Union GDPR Article 28, this intermediary processing classifies the cloud DLP proxy as a formal Data Processor, requiring complex Data Processing Agreements (DPAs), third-party risk management (TPRM) assessments, and introducing WAN latency penalties of 150ms to 350ms.
Furthermore, cleartext data ingested into Retrieval-Augmented Generation (RAG) vector embeddings creates irremediable liability under GDPR Article 17 (Right to Erasure), as mathematical vector spaces cannot excise individual entity records without full database deletion and re-indexing.
- Model Training Memorization: Foundation model providers training on user prompts or fine-tuning weights cannot memorize PII that was never transmitted.
- Vendor Log & Cache Exposure: Cloud LLM providers log only synthetic tokens (
[PATIENT_1],[IBAN_2]), neutralizing API provider data breaches. - Centralized Proxy Honeypots: Zero-Trust architecture eliminates the proxy server entirely; no central database of enterprise prompts exists to breach.
02. Formal Mathematical Foundation
Let an input payload or prompt P represent a sequence of tokens composed of non-sensitive tokens U and sensitive entities S:
M = {m_1, m_2, ..., m_k}, where each m_i = "[TYPE_N]"
Payload_wan = U ∪ M
ΔEgress(S) ≡ 0.00 bytes ∀ t ∈ [0, ∞)
I(S; Payload_wan) ≡ 0 bits ⇒ H(S | M) = H(S)
Zero mutual information leakage across network perimeter.
R ⊆ M_volatile, DiskWrite(R) ≡ 0, H(S | M, R) = 0
P_final = T^(-1)(P_out, R)
Because mapping dictionary R exists solely within volatile memory M_volatile of the client node and is never transmitted over external sockets, no third-party infrastructure ever achieves custody of cleartext entities. Subprocessor liability is mathematically nullified.
03. The 4 Non-Negotiable Invariants
Any software implementation, browser extension, SDK, or agent connector claiming ZTDS Verified™ status MUST demonstrably enforce all four non-negotiable invariants:
Mathematical Socket Egress Elimination
Raw PII, PHI, financial accounts, or credentials must NEVER traverse an external network socket unmasked. Sanitization occurs strictly prior to socket write. Evaluated via raw TCP/TLS packet inspection: Egress(S) == 0.00 bytes.
Bijective Semantic Preservation & Sub-2ms Latency
Surrogate tokens ([PATIENT_1], [EMAIL_1]) preserve semantic context and grammatical category for LLM synthesis. Inversion T^(-1) must be bijective and execute with deterministic speed under 2.0ms per 15,000 characters.
Volatile Memory Boundary & Zero Secondary Storage
Cleartext entity mappings R MUST exist exclusively in volatile RAM. Writing session state to localStorage, cookies, IndexedDB, unencrypted swap, or analytics disk logs is strictly prohibited. Multi-user session sharing mandates Argon2id and XChaCha20-Poly1305 encryption.
Complete DPA Exemption under GDPR Article 28
The software provider acts strictly as a localized computational utility executing inside the customer's hardware perimeter. Because exactly 0.00 bytes of data are transmitted to the vendor, the vendor is legally excluded from GDPR Article 28 Data Processor status (under CJEU Case C-582/14 Breyer and EDPB Guidelines 07/2020). Conforming deployments require zero third-party vendor DPAs or BAA chains.
04. Bijective Surrogate Token Taxonomy & 30 Specialized Profiles
ZTDS RFC v1.0 establishes a strict two-layer classification hierarchy. Universal personal identifiers are sanitized via a high-performance open baseline (REGEX_RULES), while specialized regulatory, clinical, and infrastructure patterns are enforced across 30 discrete industry profiles (PROFILE_RULES):
[NAME_N] — First/Last names, honorifics, corporate and legal entities
[EMAIL_N] — RFC 5322 compliant personal and corporate email addresses
[PHONE_N] — International E.164, national formatted phone and fax numbers
[ID_N] / [SSN_N] — SSN, EIN, Passport, Driver License, national resident IDs
[ADDRESS_N] — Physical street addresses, P.O. Boxes, postal codes, unit numbers
[IP_ADDR_N] — IPv4, IPv6 addresses, localhost socket bindings, internal hostnames
[LOCATION_N] — Decimal and DMS coordinates, precise GPS waypoints, city/region pairs
[DATE_N] — Dates of birth (DOB), person-associated dates
[FINANCIAL_N] — Luhn-validated credit/debit PANs, crypto addresses, routing numbers
05. Context Preservation & Anti-Mutation Rules
To guarantee that LLMs execute valid clinical, financial, or legal reasoning, surrogate tokens retain grammatical part-of-speech context. For example:
Anti-Mutation Fuzzy Token Recovery: Foundation models occasionally mutate token brackets (e.g. translating [NAME_1] to (NAME_1) or splitting across sub-word BPE boundaries). Compliant de-tokenizers must implement fuzzy regex recovery:
const FUZZY_RECOVERY_REGEX = /[\[\(\{<]([A-Z_]+)[ _-]?(\d+)[\]\}\)>]/gi;06. Standard Verification Schemas
All entries submitted via the GitOps gateway (/apply/) are validated against versioned JSON schemas:
{
"id": "privacyscrubber-web",
"name": "PrivacyScrubber Web",
"slug": "privacyscrubber-web",
"url": "https://privacyscrubber.com?utm_source=ztds.ai&utm_medium=ecosystem_registry&utm_campaign=canonical_pioneer",
"category": "Client-Side Data Sanitization App",
"tier": "Reference Implementation",
"license": "Commercial / Proprietary",
"architecture": "RAM-Only V8 Engine / In-Memory Regex",
"verified_date": "2026-09-15",
"verified_hash": "sha256:7f83b1659a72...",
"badge_url": "https://ztds.ai/badge/privacyscrubber-web.svg",
"frameworks": ["GDPR", "HIPAA Safe Harbor", "SOC 2 Type II", "EU AI Act Art. 50"]
}{
"id": "brandmeweb",
"slug": "brandmeweb",
"name": "BrandMeWeb",
"tier": "Founding Corporate Member",
"industry": "Technical SEO & GEO",
"url": "https://brandmeweb.com",
"headquarters": "International",
"verified_date": "2026-09-15",
"compliance_scope": "Full ZTDS client-side policy enforced across internal LLM workflows."
}07. Statutory Safe Harbors & GRC Cross-Mapping
| Framework | Statutory Section | ZTDS Conformance Invariant | Compliance Impact |
|---|---|---|---|
| EU GDPR | Art. 28 (CJEU C-582/14 & EDPB 07/2020) | Invariant 1 & 4: Software vendor is excluded from Data Processor status; local computational utility transmits 0.00 bytes to vendor | DPA Exempt |
| EU GDPR | Article 17 | Invariant 1: RAG vector databases store zero cleartext PII; zero re-indexing | Right to Erasure |
| US HIPAA | 45 CFR § 164.514(b) | Invariant 1 & 2: Removal of all 18 PHI identifiers prior to socket egress | Safe Harbor |
| EU AI Act | Article 50 · Art. 99 | Invariant 2 & 3: SHA-256 audit digests confirm zero prohibited model manipulation | Transparent |
| US Federal Law | FRE 502(b) | Invariant 3: Reasonable precautions preventing attorney-client privilege waiver | Non-Waiver Shield |
| SOC 2 Type II | TSC CC6.7 · CC6.8 | Invariant 1: Eliminates unencrypted sensitive data transmission over public WAN | Verified Boundary |
08. Cryptographic Transport Handoff Protocol
When multi-user teams or distributed agent swarms require collaborative re-identification, the mapping dictionary R is encrypted prior to transport using:
- Key Derivation: Argon2id (RFC 9106) configured with memory cost 19 MiB, time cost 2 iterations, parallelism 1.
- Authenticated Symmetric Cipher: XChaCha20-Poly1305 with 256-bit key and 192-bit random nonce generated via CSPRNG.
- Central Relay Demarcation: The coordination relay acts solely as a blind ciphertext pipe with zero mathematical capability to derive keys or decrypt tokens.
09. Empirical Benchmarks & Airplane Audit
Every certified implementation must pass the 5-step Airplane Mode Audit Protocol:
Audited in Open Science Framework benchmark DOI: 10.17605/OSF.IO/5BYJF.
10. GitOps Consortium Governance
The ZTDS standard is maintained as an open public specification under the Apache 2.0 and CC BY 4.0 licenses by the ZTDS AI Consortium:
- WG-1: Core Architecture & Cryptography — Invariant definitions, entropy leak bounds, formal mathematical proofs.
-
WG-2: Registry & Certification Authority — Verification audits, GitOps PR merges to
data/registry.json, SVG trust badge issuance. - WG-3: Systems, WASM & Reference SDK — Headless engine development, MCP stdio gateways, LangChain and LlamaIndex blueprints.