OWASP LLM02 Sensitive Information Disclosure: Controlling PII Before It Reaches the Model
OWASP lists Sensitive Information Disclosure as LLM02 in the 2025 edition of its Top 10 for LLM Applications. ZTDS addresses the input side of that risk: personal data, secrets, and confidential identifiers are tokenized in client memory before a prompt, document, or tool result is sent to any model provider.
Summary
LLM02:2025 describes applications that expose confidential data, proprietary information, or private user details because sensitive content was not sanitized or filtered. In practice, much of that exposure begins upstream: employees and agents paste customer records, credentials, and case files into prompts that leave the organization.
ZTDS RFC v1.0 places a deterministic sanitization step inside the client, so the provider only receives surrogate tokens. The original values never cross the network boundary and the token map is destroyed with the session.
Control Map: LLM02 Exposure Paths and ZTDS Position
| Exposure path | Risk | ZTDS position |
|---|---|---|
| Pasted prompts | Customer or employee identifiers reach a third-party provider and its retention systems. | Directly addressed. Identifiers are tokenized in RAM before transmission (Invariants 1 and 2). |
| Uploaded documents | Contracts, clinical notes, and spreadsheets carry structured identifiers into model context. | Directly addressed for structured identifiers; free-text context is reduced through specialized profiles. |
| Agent tool output | Tool results returned to the model contain secrets or records. | Addressed when the tool call passes through the local gateway (see the MCP mapping). |
| Model output | The model reveals memorized training data or prior session content. | Out of scope. This requires provider-side and application-side output controls. |
| Provider logging | Prompts are retained by the provider and later exposed. | Reduced. The provider stores tokens rather than original values. |
How ZTDS Applies
ZTDS contributes four invariants to an LLM02 control set:
- Invariant 1 — Zero cleartext egress: identifiers are replaced before any network socket call leaves the host boundary.
- Invariant 2 — Deterministic reversible surrogates: tokens such as
[EMAIL_1]preserve syntax and meaning so the model remains useful, and the mapping is restored locally. - Invariant 3 — Volatile RAM isolation: the token map lives in host memory only and is zeroized at the end of the session.
- Invariant 4 — Zero external subprocessors: no third party participates in the sanitization step.
Teams typically evidence the control with a local SHA-256 compliance receipt generated at sanitization time, which records entity categories and counts without recording the values themselves.
What This Control Does Not Cover
- It does not mitigate prompt injection (LLM01) or excessive agency (LLM06). Those require separate controls.
- It does not prevent a model from emitting sensitive data it learned during training.
- Free-text narratives can still carry contextual quasi-identifiers that no pattern-based method removes completely.
- It is a technical control, not an OWASP certification. OWASP does not certify products against its Top 10.
Frequently Asked Questions
Which OWASP item covers sensitive data leaving through prompts?
In the 2025 OWASP Top 10 for LLM Applications, Sensitive Information Disclosure is LLM02:2025. Pre-egress tokenization reduces the amount of sensitive data that reaches a provider, which narrows the input-side exposure that LLM02 describes.
Does ZTDS stop an LLM from leaking training data?
No. ZTDS operates before data leaves the client. It cannot control what a model memorized during training or what it generates; output filtering and provider assurances address that path.
How is the control evidenced to an auditor?
The sanitization step can emit a local SHA-256 compliance receipt listing entity categories and counts. The receipt contains no original values, so it can be shared with auditors without creating a new disclosure.
Related Specifications and Tools
- ZTDS RFC v1.0 Specification — The four invariants referenced on this page.
- Perimeter Scanner — Browser-based egress audit with local receipts.
- Global Regulatory Compliance Matrix — Cross-framework statutory mapping.
- Framework Mappings Hub — All framework mappings in one index.
- NIST AI RMF Generative AI Profile — Places ZTDS across GOVERN, MAP, MEASURE, and MANAGE for generative AI data privacy risk.
- EU AI Act Article 10 Data Governance — Describes how pre-ingestion sanitization supports Article 10 data governance practices.
- GDPR Articles 25 and 32 for AI Prompts — Explains data protection by design and security of processing for prompts sent to AI providers.
- HIPAA Safe Harbor for LLM Prompts — Shows how 18-identifier removal applies to clinical text sent to language models.
- MCP stdio PII Sanitization — Describes a local gateway that sanitizes JSON-RPC traffic over the MCP stdio transport.
- RAG Pipeline PII Sanitization — Places sanitization at ingestion, retrieval, and prompt assembly stages of a RAG pipeline.
- Client-Side Sanitization vs Proxy DLP — Compares client-side in-memory sanitization with network proxy and cloud DLP approaches.