Zero-Trust Data Sanitization™ (ZTDS™) 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. System Execution & Memory Boundary Foundation
ZTDS defines strict physical execution and memory boundary constraints on the local computing host. Let an input stream P represent a token sequence composed of non-sensitive tokens U and sensitive entities S:
M = {m_1, m_2, ..., m_k}, where each surrogate token m_i = "[TYPE_N]"
Payload_socket = U ∪ M
ΔEgress(S) ≡ 0.00 bytes ∀ t ∈ [0, ∞)
Information-Theoretic Security: I(S; Payload_socket) ≡ 0 bits
Zero cleartext entity state crosses the OS network interface controller (NIC).
R ⊆ Host_Volatile_RAM, DiskWrite(R) ≡ 0, NonVolatileStorage ≡ ∅
P_final = T^(-1)(Response_payload, R) — Reconstructed solely on the client endpoint.
Because mapping table R exists solely within volatile heap memory of the client host process and is strictly blocked from secondary non-volatile media and outbound network interfaces, no third-party infrastructure or external subprocessor ever gains custody of cleartext data. Subprocessor classification under GDPR Article 28 is completely eliminated.
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:
Physical Socket Egress Elimination
The mandatory architectural rule that raw personally identifiable information (PII), protected health information (PHI), financial accounts, or corporate secrets must never cross the local hardware or process perimeter unmasked. Sanitization occurs strictly prior to socket write, physically guaranteeing zero external data egress: Egress(S) == 0.00 bytes.
Bijective Semantic Preservation & Sub-2ms Latency
The mandatory requirement that sensitive entities are replaced with grammatically consistent surrogate tokens ([PATIENT_1], [EMAIL_1]) that preserve model reasoning context while token mapping dictionaries remain exclusively in local volatile memory. Reversible inversion must be strictly bijective and execute deterministically with sub-2.0ms latency per 15,000 characters.
Volatile Memory Boundary & Zero Secondary Storage
The execution boundary rule requiring that all cleartext entity mappings R, surrogate lookup tables, and session keys exist exclusively within local volatile RAM (or sandboxed WebAssembly/Nitro Enclave perimeters). Writing unencrypted session state to disk, browser storage, unencrypted swap, or third-party telemetry sockets is strictly prohibited.
Complete DPA Exemption under GDPR Article 28
The statutory compliance invariant establishing that the sanitization engine functions as a localized computational utility within customer premises rather than a hosted SaaS subprocessor. Because zero customer data egresses to vendor infrastructure, the vendor is excluded from Data Processor classification under GDPR Article 28 (CJEU Case C-582/14 Breyer), eliminating third-party DPA and BAA liabilities.
Physical In-RAM Execution Topology & Zero Subprocessor Guarantee
ZTDS RFC v1.0 strictly rejects proxy-based sanitization. Traditional "secure cloud proxies" intercept unencrypted HTTP traffic mid-transit, inspect payloads in a third-party cloud data center, and reconstruct prompts before dispatching them to LLM APIs. This paradigm fundamentally violates the Zero-Trust mandate by creating a centralized cloud honeypot and introducing a mandatory subprocessor under GDPR Article 28.
All entity tokenization, surrogate generation, and session mapping tables execute strictly in volatile process RAM. No unmasked data crosses the network socket or disk storage.
Because 0.00 B of user data ever reaches the software vendor, the vendor is legally excluded from Data Processor status. Conforming implementations are 100% DPA and BAA exempt.
Compatible with sandboxed WebAssembly (WASM), Nitro Enclaves, and OS process-isolated dynamic binaries (C-ABI) with sub-0.8ms local execution latency.
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 | Phase 2 · Art. 10 & 50 | Invariant 1, 2 & 3: Pre-egress sanitization prevents prompt leakage and training set contamination in autonomous agentic loops | Phase 2 Compliant |
| NIST AI RMF 600-1 | GenAI Profile Sec. 4.12 | Invariant 1 & 3: Ephemeral client RAM boundary physically blocks sensitive data disclosure, prompt extraction, and model poisoning | SP 600-1 Aligned |
| ISO/IEC 42001 | Annex A.6, A.7 & A.8 | Invariant 2 & 4: Contextual in-process surrogate tokenization enforces AI data provenance and isolates third-party LLM supplier risk | AIMS Conformant |
| ISO/IEC 27001 | Control A.8.11 | Invariant 1 & 2: Cryptographic presentation-layer data masking applied prior to external socket transmission | Masking Certified |
| 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 |
Mandates strict data governance under Article 10 for AI deployers. ZTDS mathematically immunizes agentic tool-use loops (MCP, LangChain) by enforcing local in-memory tokenization before prompt data reaches General-Purpose AI (GPAI) endpoints.
Maps directly to NIST SP 600-1 Risk 12 (Sensitive Data Disclosure) controls GOVERN-1.2, MAP-1.5, and MANAGE-2.4. Zero-egress RAM isolation physically eliminates prompt extraction and training set data contamination.
Fulfills Annex A.6 (AI Data Lifecycle), A.7 (Security), and A.8 (Third-Party Supplier Risk). By converting sensitive entities into context-preserving surrogates locally, enterprise controllers eliminate third-party AI subprocessor liability.
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.
Model Context Protocol (MCP) Process-Isolated In-RAM Profile
For agentic tool-use loops, developer environments (Cursor, Windsurf, Claude Desktop, Zed), and headless CLI processes, ZTDS standardizes the in-memory stdio stream interceptor. The local reference daemon (ztds-mcp v1.1.1) intercepts tool arguments, diffs, and prompt strings across stdio JSON-RPC pipes in < 0.5ms, enforcing Invariants 1–4 with 0.00 bytes socket egress prior to cloud model transmission.
09. Empirical Benchmarks & Airplane Audit
Every certified implementation must pass the 5-step Airplane Mode Audit Protocol:
Empirical evaluation across OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet, Google Gemini 2.0 Pro, and DeepSeek-V3 measuring cleartext leakage prevention, bijective fidelity, and microsecond latency:
| Frontier Model | Raw Egress (No ZTDS) | Protected Egress | LPR Rate | Bijective Fidelity |
|---|---|---|---|---|
| openai/gpt-4o | 100.0% | 0.00% | 100.0% | 100.0% |
| anthropic/claude-3-5-sonnet | 100.0% | 0.00% | 100.0% | 100.0% |
| google/gemini-2.0-pro | 100.0% | 0.00% | 100.0% | 100.0% |
| deepseek/deepseek-v3 | 100.0% | 0.00% | 100.0% | 100.0% |
Audited in Open Science Framework benchmark DOI: 10.17605/OSF.IO/5BYJF. Reproduce via CLI: npx ztds-bench.
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.