ZTDS AI Consortium

Tel Aviv Israel support@privacyscrubber.com https://ztds.ai/

Security Network Working Group Zero-Trust Data Sanitization PII Redaction Large Language Models Generative AI In-Memory Computing Privacy-Preserving AI This document specifies the Zero-Trust Data Sanitization (ZTDS) protocol, an architectural framework and execution standard designed to eliminate personally identifiable information (PII), protected health information (PHI), payment card data, and corporate credentials from unstructured text payloads prior to ingestion by remote Large Language Models (LLMs) and autonomous AI 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 executed strictly on the client or private host boundary, precluding intermediate cloud proxy interception, prompt injection exfiltration, and persistent vector database poisoning.

Introduction The rapid deployment of frontier generative artificial intelligence (AI), Retrieval-Augmented Generation (RAG) architectures, and autonomous multi-agent systems has exposed a fundamental security paradigm failure. Millions of enterprise users, developers, and autonomous software agents continuously transmit unstructured natural language prompts, source code repositories, clinical summaries, and financial ledgers to remote foundation model inference endpoints.

Problem Statement: The Cloud DLP Paradox Legacy enterprise data loss prevention (DLP) systems rely on intermediary cloud proxies or central inspection gateways. When applied to modern generative AI workloads, this architecture introduces four critical vulnerabilities:

1. Network Latency and Perceptual Lag: Cloud-routed DLP inspection adds round-trip network delays ranging between 150 ms and 400 ms per inference invocation, degrading real-time conversational streaming and sub-agent coordination.
2. Single Point of Data Breach: Routing cleartext organizational payloads through intermediary proxy infrastructure creates a centralized target for state-sponsored adversaries and infrastructure compromises.
3. Regulatory Subprocessor Multiplication: Under European Union General Data Protection Regulation (GDPR) Article 28, introducing a cloud inspection proxy adds a new data processor into the statutory subprocessor chain, requiring bespoke Data Processing Agreements (DPAs) and cross-border transfer assessments.
4. Transport Layer Interception Failure: As client-to-inference transport increasingly adopts end-to-end authenticated encryption, traditional network-level middleboxes require intrusive TLS certificate termination, compromising cryptographic integrity.

Architectural Paradigm: Cloud Proxy vs. Host-Native In-Memory Boundary ZTDS replaces network-boundary inspection with a host-native, client-boundary sanitization topology . All entity detection, de-identification, and surrogate replacement occur within volatile memory on the originating client device before any TCP/IP socket serialization.

Architectural Comparison: Intermediary Cloud Proxy vs. ZTDS Host-Native Perimeter | Cloud DLP | --------------> | Cloud | | Device | <-------------- | Proxy | <-------------- | LLM | +--------+ (Risk/Latency) +-----------+ (Audit Friction)+-------+ ZTDS Zero-Trust Endpoint Architecture: +-----------------------------------+ | Client Host Execution Perimeter | | +-----------+ +-------------+ | Sanitized WAN +-------+ | | Cleartext | --> | In-Memory | | ---------------> | Cloud | | | Payload S | | Engine T(S) | | <--------------- | LLM | | +-----------+ +-------------+ | Surrogate WAN +-------+ | ^ | | | | Local Inverse v | | [Volatile Session Map R in RAM] | +-----------------------------------+ ]]>

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology

Sanitization Engine:

A deterministic computational module that identifies sensitive entities within unstructured text and substitutes them with synthetic surrogate tokens.

Surrogate Token:

A non-sensitive, type-preserving synthetic placeholder (e.g., "[NAME_1]", "[EMAIL_2]") that preserves grammatical structure and semantic roles for downstream language models.

Session Mapping Dictionary (R):

A temporary bidirectional lookup table mapping surrogate tokens to original cleartext entities, maintained exclusively in volatile host memory.

De-Tokenization (Re-identification):

The reverse mapping process executed locally on the client to restore original cleartext values into model completions before user display or local application consumption.

Airplane Mode Audit:

A formal compliance procedure verifying that 100% of data sanitization and de-tokenization operations execute successfully while all network interfaces are physically or logically disconnected.

Mathematical Model and Core Invariants

Formal Model Definition Let an input text prompt or agent payload P be a finite sequence of tokens partitioned into non-sensitive tokens U and sensitive tokens S: P = U UNION S, where U INTERSECT S = EMPTYSET Where S = {s_1, s_2, ..., s_k} represents discrete identifying entity substrings matching statutory, medical, financial, or organizational classification taxonomy. Under the ZTDS protocol:

1. An in-memory sanitization transformation T: S -> M is executed locally: M = {m_1, m_2, ..., m_k} where each surrogate token m_i is an orthogonal synthetic label preserving entity syntax.
2. The sanitized payload transmitted across the external network perimeter contains strictly U UNION M: Egress(S) = 0 bytes
3. The ephemeral session map R = {(m_i, s_i) : 1 <= i <= k} is retained strictly in volatile Random Access Memory (RAM), bound exclusively to the local execution thread or tab context.
4. Upon receipt of the model inference response P_out containing surrogate tokens M, an inverse transformation T^(-1) is evaluated locally: P_final = T^(-1)(P_out, R)
5. Upon session completion, window close, or process termination, R is deterministically erased from RAM.

The Four Fundamental Invariants Any implementation claiming conformance with the ZTDS standard MUST satisfy four non-negotiable invariants:

Invariant 1: Volatile Memory Boundary (RAM-Only Isolation) Under no operational circumstances SHALL cleartext sensitive entities S or session mapping pairs R be committed to non-volatile secondary storage. This prohibition explicitly bans:

• Web browser persistent stores: localStorage, sessionStorage, IndexedDB, Cache API, and HTTP cookies.
• Operating system storage: unencrypted temporary files, persistent swap files, crash log dumps, or diagnostic event logs.
• External server infrastructure: application logging endpoints, telemetry trackers, or cloud operational analytics.

In browser runtimes, session mapping state MUST be tab-isolated (scoped strictly to the execution context of the originating browsing context) to prevent cross-session or cross-tab side-channel memory leaks.

Invariant 2: Sub-2-Millisecond Latency Ceiling To prevent human perceptual latency and avoid pipeline stall conditions in real-time autonomous multi-agent loops, the sanitization transformation T MUST execute with deterministic bounded latency:

• For interactive client prompts containing up to 15,000 characters, execution latency MUST NOT exceed 2.0 milliseconds on modern consumer client hardware.
• For high-throughput enterprise batch pipelines, sanitization throughput MUST achieve a minimum sustained rate of 10,000 records per second per CPU core, as documented in empirical latency benchmarks .

Invariant 3: Zero Outgoing Network Transmission (Airplane Mode Standard) The sanitization engine MUST be completely self-contained. All pattern compilation, regular expression matching, checksum verification (e.g., Luhn algorithm for payment cards), and surrogate substitution MUST operate with zero external network connectivity. Conformance is verified using the Airplane Mode Audit: the host device MUST successfully perform complete entity detection, substitution, and inverse reconstruction while all network interfaces (Ethernet, Wi-Fi, cellular, and loopback sockets to remote hosts) are disabled.

Invariant 4: Cryptographic Transport Handoff When distributed agent swarms or collaborative enterprise workflows require transferring session maps across host boundaries, the session map R MUST NOT be transmitted in cleartext. Serialization MUST enforce authenticated encryption with associated data (AEAD) using XChaCha20-Poly1305 with a 192-bit cryptographic nonce and key derivation via Argon2id . The intermediary relay server MUST act exclusively as an opaque blind store with zero computational ability to derive the key or decrypt cleartext entities.

Protocol Lifecycle and Operational Mechanics The ZTDS operational lifecycle progresses through six sequential phases executed within the local host boundary:

Phase 1: Ingestion and Lexical Boundary Parsing The cleartext payload P is received by the local host interface. The engine performs lexical scanning across standardized entity taxonomy classes (Section 4). To prevent catastrophic regex backtracking (ReDoS), all evaluation expressions MUST conform to linear-time deterministic finite automaton (DFA) matching semantics.

Phase 2: Contextual Surrogate Tokenization Each identified entity s_i is registered and assigned an indexed synthetic surrogate m_i. Surrogate formatting adheres strictly to bracketed syntactic labels (e.g., "[NAME_1]", "[IBAN_1]"). If the identical entity string s_i recurs multiple times within the same payload, the engine MUST map all occurrences to the identical surrogate token m_i to preserve coreference resolution for downstream language models.

Phase 3: Ephemeral Session Map Allocation The association pair (m_i, s_i) is committed to an in-memory hash map R. The map structure is tagged with a cryptographically secure random session identifier and marked for volatile lifecycle management.

Phase 4: Upstream Transmission and Inference The sanitized payload P_sanitized = U UNION M is serialized and transmitted over TLS to the remote foundation model inference provider. Because raw identifying strings never leave the client boundary, the remote provider's logging infrastructure, fine-tuning pipelines, and prompt caching systems ingest strictly synthetic surrogate identifiers.

Phase 5: Local De-Tokenization (Re-identification) Upon receipt of the inference response P_out from the foundation model, the client runtime parses the stream for surrogate token patterns. Each occurrence of m_i is matched against local session map R and replaced with corresponding original value s_i: [NAME_1] acct [IBAN_1]" Model Output: "Confirmation: scheduled transfer for [NAME_1]." Reconstructed: "Confirmation: scheduled transfer for Alice Smith." ]]> The end user or local consumer receives complete grammatical fidelity without any cleartext exposure to the cloud model provider.

Phase 6: Deterministic Memory Erasure Upon user session termination, tab close, or explicit pipeline teardown, the host runtime MUST execute a zero-fill overwrite or release of the memory buffer hosting R. In runtimes lacking manual memory management (e.g., JavaScript engines), object references MUST be nullified immediately, and WeakMap structures SHOULD be utilized to allow instantaneous garbage collection.

Surrogate Token Taxonomy To maintain natural language fluency and attention head alignment across diverse foundation model architectures (Transformer, SSM, MoE), surrogate tokens MUST conform to standard bracketed uppercase identifiers: Standardized ZTDS Surrogate Token Taxonomy

Entity Classification	Canonical Token Format	Syntactic Example
Personal Full Name	[NAME_N]	"John Doe" -> "[NAME_1]"
Electronic Mail Address	[EMAIL_N]	"user@enterprise.org" -> "[EMAIL_1]"
Telephone / Mobile Number	[PHONE_N]	"+1-555-0199" -> "[PHONE_1]"
Government / National ID / SSN	[NAT_ID_N] / [SSN_N]	"123-45-6789" -> "[SSN_1]"
Payment Card (Luhn Validated)	[CARD_N]	"4532...8812" -> "[CARD_1]"
International Bank Account (IBAN)	[IBAN_N]	"GB29XAAA10203012345678" -> "[IBAN_1]"
Protected Health Identifier (PHI/MRN)	[MRN_N] / [PATIENT_N]	"MRN-889104" -> "[MRN_1]"
API Keys and Cryptographic Secrets	[SECRET_KEY_N]	"sk-live-99f...8a" -> "[SECRET_KEY_1]"
Network IPv4 / IPv6 / Hostname	[IP_ADDR_N]	"192.168.1.104" -> "[IP_ADDR_1]"

Cryptographic Transport Handoff Protocol In enterprise agent architectures where an upstream agent creates a session map that must be de-tokenized by a downstream agent running on a distinct host node, the session map MUST be encrypted prior to transit across intermediate networks.

Cipher and Key Derivation Parameters The cryptographic handoff protocol mandates the following primitives:

• Key Derivation Function: Argon2id conforming to . Minimum operational parameters: Memory = 64 MiB (65536 KiB), Iterations = 3, Parallelism = 1.
• Authenticated Symmetric Encryption: XChaCha20-Poly1305 AEAD cipher conforming to with extended 192-bit (24-byte) nonces generated using a cryptographically secure pseudorandom number generator (CSPRNG).
• Associated Data: The AEAD associated data MUST bind the session UUID and expiration timestamp to prevent ciphertext replay and splicing attacks.

Verification and Conformance Audit Compliance with this specification requires verifiable testing under adversarial boundary conditions:

The 5-Step Airplane Mode Audit Procedure

1. Initialize the host application or agent runtime with a test corpus containing statutory PII and secrets.
2. Physically disconnect or logically disable all network adapters (Wi-Fi, Ethernet, LTE/5G).
3. Execute complete document sanitization. Verify that output contains strictly surrogate tokens.
4. Simulate a model response containing surrogate tokens and execute local de-tokenization. Confirm 100% string restoration.
5. Inspect host operating system socket tables to confirm exactly zero packets were emitted during the entire test sequence.

Conformance Test Vectors The following test vector illustrates a standardized ZTDS execution sequence: [NAME_1] (MRN: [MRN_1], Phone: [PHONE_1]) authorized payment using Visa [CARD_1] to Dr. [NAME_2]." Volatile Session Map R: { "[NAME_1]": "Sarah Connor", "[MRN_1]": "902-114-88", "[PHONE_1]": "+1-555-0144", "[CARD_1]": "4111111111111111", "[NAME_2]": "Marcus Vance" } Inference Response Inbound: "Billing confirmed for [NAME_1] under clinical file [MRN_1]." Restored Client Display: "Billing confirmed for Sarah Connor under clinical file 902-114-88." ]]>

IANA Considerations This document has no IANA actions.

Security Considerations This entire document specifies security and privacy architecture. In conformance with BCP 72 , the following threat scenarios are analyzed:

Prompt Injection and Training Data Exfiltration Adversaries executing indirect prompt injection attacks against LLMs attempt to manipulate model context into revealing private user records. Under ZTDS, because raw PII never enters the model context window, prompt injection attacks cannot exfiltrate original credentials; the attacker can at most observe synthetic surrogate labels.

Local Host Memory Inspection and Swap Analysis If an adversary achieves root-level compromise of the client operating system, they may inspect volatile memory buffers. To mitigate this, compliant implementations SHOULD use memory locking (e.g., mlock on POSIX systems) to prevent volatile memory from being paged to unencrypted swap disks, and explicitly zero memory buffers upon deallocation.

Surrogate Token Collision and Ambiguity If an input prompt naturally contains text matching the surrogate regex syntax (e.g., a software tutorial discussing "[NAME_1]"), the engine MUST escape or disambiguate literal brackets using namespace prefixes to prevent accidental de-tokenization collision.

Privacy Considerations In accordance with , ZTDS provides deterministic technical and organizational measures (TOMs) satisfying global privacy statutes:

• GDPR Article 28 Exemption: By eliminating cleartext PII transmission across the WAN, downstream foundation model vendors never process personal data in cleartext, preventing SaaS vendor lock-in to burdensome subprocessor compliance chains.
• Right to be Forgotten (GDPR Article 17): When AI models or vector databases ingest strictly surrogate tokens, an individual exercising their deletion right requires only erasing the local ephemeral session key; all remote embeddings and logs remain permanently de-identified and mathematically un-linkable.
• HIPAA Safe Harbor De-Identification: Replacing all 18 statutory HIPAA identifiers with surrogate tokens fulfills 45 CFR Section 164.514(b) requirements prior to cloud ingestion.

References Normative References Informative References