Network Working Group I. Sibiryakov Internet-Draft PrivacyScrubber Intended status: Informational September 2026 Expires: March 2027 The Zero-Trust Data Sanitization (ZTDS) Protocol for Frontier Artificial Intelligence Ingestion draft-sibiryakov-ztds-protocol-00 Abstract This document specifies the Zero-Trust Data Sanitization (ZTDS) protocol, an endpoint-native architectural framework designed to eliminate personally identifiable information (PII), protected health information (PHI), and confidential corporate credentials from unstructured text payloads prior to ingestion by remote Large Language Models (LLMs) and autonomous agents. ZTDS enforces strict in-memory execution within volatile Random Access Memory (RAM), ephemeral surrogate tokenization, tab-isolated session mapping, and mathematically verifiable zero network egress of raw identifying data. Reversible mapping is achieved exclusively on the client boundary using authenticated encryption with associated data (AEAD), precluding intermediate cloud proxy retention, prompt injection extraction, and persistent vector database poisoning. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 26, 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Threat Model and Boundary Invariants . . . . . . . . . . . . . . 3 2.1. In-Memory Volatility . . . . . . . . . . . . . . . . . . . 3 2.2. Zero Network Egress . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Architecture . . . . . . . . . . . . . . . . . . . . . 4 3.1. Parsing and Entity Extraction . . . . . . . . . . . . . . . 4 3.2. Contextual Tokenization . . . . . . . . . . . . . . . . . . 4 3.3. Session Mapping and De-Tokenization . . . . . . . . . . . . 5 4. Cryptographic Handoff Protocol . . . . . . . . . . . . . . . . . 5 5. Security and Privacy Considerations . . . . . . . . . . . . . . 6 6. Regulatory Mapping (GDPR, HIPAA, EU AI Act) . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 1.1. Problem Statement The widespread adoption of generative artificial intelligence (AI) and cloud-hosted foundation models (e.g., GPT-4, Claude, Gemini) introduces critical privacy vulnerabilities into enterprise networks. Users routinely submit sensitive prompts containing Personally Identifiable Information (PII), patient health records, attorney- client privileged communications, and API credentials. Traditional Data Loss Prevention (DLP) gateways intercept traffic at the network boundary via cloud proxies. This introduces three severe defects: (1) network latency (>200ms per request), (2) architectural data egress to intermediate proxies, and (3) operational failure under end-to-end transport encryption (TLS). The foundational architecture of Zero-Trust Data Sanitization [ZENODO-ZTDS] mitigates these risks by performing all transformation strictly on the host. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Threat Model and Boundary Invariants 2.1. In-Memory Volatility An implementation conforming to ZTDS MUST execute all parsing, regular expression matching, and token replacement operations inside volatile Random Access Memory (RAM). No cleartext PII or session maps SHALL be written to persistent storage (e.g., cookies, Web Storage, disk caches, or swap files). 2.2. Zero Network Egress The client device MUST NOT transmit cleartext identifiers across any TCP/IP network socket. All redaction operations MUST complete prior to HTTP request serialization. A conforming implementation MUST be fully operational when the client device is in an air-gapped or "Airplane Mode" operational state. 3. Protocol Architecture 3.1. Parsing and Entity Extraction The inbound text payload is evaluated by a deterministic tokenization engine operating across universal and vertical-specific classes (including statutory personal names, telephone numbers, national identity numbers, payment cards, medical record numbers, and cryptographic credentials). 3.2. Contextual Tokenization Detected entities are replaced with type-consistent synthetic surrogate tokens conforming to the format: "[" ENTITY_TYPE "_" ENTITY_INDEX "]" Example: "John Doe" is mapped to "[NAME_1]". This preserves the syntactic and grammatical integrity of the prompt for subsequent linguistic analysis by the downstream language model. 3.3. Session Mapping and De-Tokenization A bidirectional, ephemeral session map is maintained in volatile memory: { "[NAME_1]": "John Doe" } When the remote model produces a completion containing surrogate tokens, the client performs local reverse mapping (de-tokenization) to restore original values without exposing cleartext to intermediate parties. 4. Cryptographic Handoff Protocol When multi-party collaboration or session handoff is required, the session map MUST be serialized using authenticated encryption. The standard mandates XChaCha20-Poly1305 with key derivation via Argon2id (minimum memory: 64MB, iterations: 3, parallelism: 1). Empirical benchmarking [OSF-BENCH] validates sub-millisecond local execution overhead compared to network proxy alternatives. 5. Security and Privacy Considerations Surrogate tokens prevent model memorization and protect against prompt injection attacks aiming to exfiltrate private training data or user context. Because raw values never reach model parameters or server-side inference logs, compliance with statutory data minimization mandates is achieved deterministically. 6. Regulatory Mapping ZTDS satisfies the requirement of Technical and Organizational Measures (TOMs) under GDPR Article 32, Data Protection by Design under GDPR Article 25, and the De-Identification standard under HIPAA Safe Harbor (45 CFR Section 164.514(b)). 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [ZENODO-ZTDS] Sibiryakov, I., "Zero-Trust Data Sanitization (ZTDS) Protocol Specification", CERN Zenodo, DOI: 10.5281/zenodo.22058770, September 2026. [OSF-BENCH] Sibiryakov, I., "Empirical Latency and Memory Profiling of Client-Side vs Cloud Proxy Data Sanitization", Center for Open Science, DOI: 10.17605/OSF.IO/5BYJF, September 2026. Author's Address Ilya Sibiryakov PrivacyScrubber Research / BrandMeWeb Tel Aviv Israel Email: support@privacyscrubber.com / info@brandmeweb.com URI: https://privacyscrubber.com/