The Zero-Trust Data Sanitization (ZTDS) Protocol for Frontier Artificial Intelligence Ingestion

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 31 March 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

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 [ZTDS-LATENCY]), 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.¶

2. 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 [RFC2119] [RFC8174] 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.¶

3. 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.¶

4. 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.¶

5. The Four Protocol Invariants

Every compliant implementation of the ZTDS protocol MUST satisfy four normative invariants, with formal mathematical proofs detailed in [ZTDS-PROOF]:¶

T^(-1)( T(S) ) == S

6. Surrogate Token Taxonomy

Surrogate tokens follow standardized bracketed notation to ensure cross-vendor compatibility:¶

7. 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 [RFC9106] 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 [RFC8439] principles.¶

• Zero Relay Custody: Coordination relays act exclusively as blind encrypted conduits with zero mathematical capability to derive keys or inspect mapping pairs.¶

8. 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 [RFC8032]. 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.¶

9. IANA Considerations

This document has no IANA actions.¶

10. Security Considerations

11. 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 [ZTDS-LEGAL].¶

Author's Address