ZTDS AI Consortium / BrandMeWeb

ilya@brandmeweb.com https://ztds.ai

Security Independent Submission zero-trust data sanitization large language models generative ai in-memory privacy pii de-identification gdpr hipaa Zero-Trust Data Sanitization (ZTDS) defines a formal architectural standard and execution protocol for client-side, in-memory de-identification and re-identification across Generative Artificial Intelligence (GenAI), Retrieval-Augmented Generation (RAG), and autonomous agent workflows. Under ZTDS, sensitive information (including Personally Identifiable Information (PII), Protected Health Information (PHI), financial account numbers, and developer secrets) is intercepted and transformed into synthetic surrogate tokens strictly within volatile memory (RAM) of the originating client or private host node before network serialization. This protocol specification formalizes the threat model, the four core invariants, surrogate token syntaxes, cryptographic transport handoffs, and verification procedures required for interoperable, zero-subprocessor implementations.

Introduction The proliferation of Generative Artificial Intelligence (GenAI) and Large Language Model (LLM) APIs has created severe data exposure risks. Organizations transmitting unmasked corporate documents, healthcare records, source code, and customer communications over the Public Internet risk compromising sensitive information during model training, telemetry harvesting, or third-party cloud breaches. Prior approaches have relied on two predominant architectures, each with critical shortcomings:

1. Network Gateways and Total Blockades: Prohibiting corporate AI access entirely. This strategy induces widespread employee circumvention ("Shadow AI"), leading to uncontrolled cleartext data exposure.
2. Cloud-Based Data Loss Prevention (Cloud DLP) Proxies: Intercepting and inspecting WAN traffic via intermediate multi-tenant cloud services. This introduces significant network round-trip latencies (typically 150ms to 350ms, as empirically measured in ), establishes a single point of data compromise, and introduces an additional Data Processor under European Union General Data Protection Regulation (GDPR) Article 28, mandating cumbersome Data Processing Agreements (DPAs).

The Zero-Trust Data Sanitization (ZTDS) protocol shifts the security perimeter directly into volatile memory (RAM) of the local execution context. No sensitive data may be serialized into network sockets prior to mathematical de-identification. This document specifies the normative requirements for conformant ZTDS implementations.

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

Cleartext Entity (S):

A sensitive substring matching regulatory or organizational classification rules (e.g., patient name, credit card number, API secret).

Surrogate Token (M):

A structured, synthetic replacement token preserving semantic and syntactic properties without revealing cleartext.

Session Mapping Dictionary (R):

An ephemeral table linking surrogate tokens to cleartext entities, held exclusively in volatile memory.

Airplane Mode Standard:

An empirical test confirming that sanitization and inverse restoration execute with zero network packets emitted across all interfaces.

Threat Model and Assumptions The ZTDS threat model operates under the following security assumptions:

• Untrusted Transport: The Wide Area Network (WAN) and all intermediary proxy servers are assumed to be monitored or subject to lawful/unlawful interception.
• Untrusted Remote Model: The upstream AI model provider (e.g., public LLM API endpoint) is treated as an untrusted third party that MUST NOT receive cleartext sensitive data, preventing training set ingestion or prompt logging.
• Semi-Trusted Host Application: The host execution environment (e.g., browser tab, container, or IDE process) is trusted for local volatile execution, but secondary storage (disk, browser databases, unencrypted telemetry caches) is treated as an insecure persistent boundary.

The primary objective of ZTDS is guaranteeing: Egress(S) == 0 bytes Where S represents the set of all sensitive entities detected within an input prompt or payload.

Mathematical Specification of Protocol Let an input prompt or agent payload P be a sequence of tokens composed of non-sensitive tokens U and sensitive tokens S: P = U union S, where U intersect S = empty_set Where S = {s_1, s_2, ..., s_k} represents discrete sensitive entity instances. A conformant ZTDS transformation T operates locally as follows:

1. An in-memory transformation T: S -> M is computed locally: M = {m_1, m_2, ..., m_k}, where each m_i is a structured surrogate token.
2. The ephemeral reverse dictionary R = {(m_i, s_i)} is allocated strictly in volatile RAM scoped to the active execution context.
3. The payload serialized and dispatched over the network contains strictly U union M.
4. Upon receipt of the AI inference response P_out containing surrogate tokens M, the local inverse transformation T^(-1): M -> S restores the cleartext entities exclusively on the local presentation layer: P_final = T^(-1)(P_out, R).
5. Upon process termination or session destruction, R MUST be purged from memory.

The Four Protocol Invariants Every compliant implementation of the ZTDS protocol MUST satisfy four normative invariants, with formal mathematical proofs detailed in :

Invariant 1: Volatile Memory Boundary (RAM-Only Isolation) Under no circumstances SHALL cleartext entity values S or mapping pairs R be persisted to secondary storage. Implementations MUST NOT write session mapping state to:

• Browser storage subsystems: localStorage, sessionStorage, IndexedDB, document.cookie.
• Host non-volatile storage: temporary files, swap space, disk caches, or crash log dumps.
• Application logging frameworks: debug logs, operational analytics, or tracing pipelines.

In multi-threaded or browser environments, mapping dictionaries MUST be strictly process-isolated or tabId-scoped to prevent cross-session leakage.

Invariant 2: Deterministic Reversible Tokenization Surrogate tokens MUST preserve the syntactic category and semantic spacing of the original entity to prevent LLM reasoning degradation. The transformation MUST guarantee: T^(-1)( T(S) ) == S The sanitization engine MUST execute with a deterministic latency bound: Latency(T) < 2.0 ms for standard payloads up to 15,000 characters on standard computing architectures.

Invariant 3: Zero Outgoing Network Transmission (Airplane Mode Standard) The sanitization and de-tokenization mechanisms MUST be completely self-contained within local runtime code. Implementations MUST be verifiable via the 5-step Airplane Mode Audit:

1. Ingest sensitive payload into application memory.
2. Sever all physical and virtual network interfaces.
3. Execute sanitization transformation T.
4. Execute reverse re-identification transformation T^(-1).
5. Confirm 100% functional execution with 0 socket errors and 0 bytes egressed.

Invariant 4: Zero Sub-Processor Chain The sanitization engine MUST operate as a pure computational utility on the host device. It MUST NOT transmit telemetry, telemetry pings, entity frequencies, or usage metrics to external collection servers. This exclusion relieves the deployment from third-party Data Processing Agreements under European Union GDPR Article 28.

Surrogate Token Taxonomy Surrogate tokens follow standardized bracketed notation to ensure cross-vendor compatibility: Standardized Surrogate Token Notation

Entity Class	Canonical Token Syntax	Example Transformation
Personal Name	[NAME_N]	John Doe -> [NAME_1]
Email Address	[EMAIL_N]	john@example.com -> [EMAIL_1]
Phone Number	[PHONE_N]	+1-555-0199 -> [PHONE_1]
National ID / SSN	[ID_N] / [SSN_N]	123-45-6789 -> [SSN_1]
Financial / IBAN	[IBAN_N] / [CARD_N]	GB29XAAA... -> [IBAN_1]
Protected Health / PHI	[MRN_N] / [PATIENT_N]	MRN-90123 -> [MRN_1]
Developer Secrets	[SECRET_KEY_N]	sk-ant-... -> [SECRET_KEY_1]
IP / Host Address	[IP_ADDR_N]	192.0.2.1 -> [IP_ADDR_1]

Cryptographic Transport Handoff When collaborative agent swarms or multi-node enterprise pipelines require transferring mapping state across trust boundaries, mapping dictionaries MUST be encrypted prior to transit:

• Key Derivation: Argon2id as specified in with a minimum of 19 MiB memory cost and 2 iterations.
• Authenticated Symmetric Encryption: XChaCha20-Poly1305 with a 24-byte (192-bit) cryptographically secure random nonce generated via a CSPRNG, conforming to principles.
• Zero Relay Custody: Coordination relays act exclusively as blind encrypted conduits with zero mathematical capability to derive keys or inspect mapping pairs.

Conformance Attestation Architecture Conformant implementations MAY generate cryptographically signed Conformance Certificates: ZTDS-CERT-v1.{payload_b64url}.{signature_b64url} Signatures are generated using Ed25519 as specified in . The payload encompasses a canonicalized JSON structure containing the SHA-256 tree hash of the audited source code, invariant evaluation statuses, and a 365-day validity window.

IANA Considerations This document has no IANA actions.

Security Considerations

Memory Dumps and Side-Channel Attacks While ZTDS eliminates WAN exposure, local volatile memory remains vulnerable to process inspection if the underlying operating system is compromised. Implementations deployed in high-assurance environments SHOULD utilize hardware-isolated secure enclaves (e.g., AWS Nitro Enclaves or hardware WebAssembly sandboxes) to prevent OS kernel memory dumps from harvesting ephemeral mapping tables.

Adversarial Prompt Injection Adversarial prompts designed to trick the LLM into printing mapping dictionaries are mitigated by the architecture: the remote LLM NEVER receives the mapping dictionary R. It only observes surrogate tokens [TYPE_N] as atomic entities.

Surrogate Collision and Entropy Surrogate token assignment MUST be deterministic within a given session to ensure co-reference resolution (e.g., the same person mentioned five times receives the identical [NAME_1] surrogate across all mentions), while maintaining fresh indexing per session.

Privacy and Regulatory Considerations By eliminating intermediate data processors, ZTDS satisfies European Union GDPR Article 28 exemption requirements, Article 17 Right to be Forgotten within vector databases (embeddings contain zero extractable cleartext PII), and HIPAA 45 CFR Section 164.514(b) Safe Harbor de-identification rules, as analyzed in .

References Normative References Informative References