Sensitive Information Disclosure (OWASP LLM06:2025)
What this checks
Prevents confidential data from leaking through LLM inputs or outputs. LLMs may memorize, echo, or inference-time expose PII, credentials, and business secrets embedded in prompts — to current users, future users, or via model extraction.
Vulnerable patterns
- Whole user or account records interpolated into a system or user prompt
- API keys, database passwords, or other credentials baked into prompt strings
- Returning raw LLM responses to callers without an output-redaction gate — the response can echo data injected via retrieval or memory
- Conversation history or vector-store writes that mix multiple users' content without partitioning by user identity
- Logging or telemetry that emits prompts and completions unredacted
Fix immediately
Flag the vulnerable code, explain the risk, and suggest a fix establishing these properties. Translate to the language and framework of the audited file — use that stack's secrets manager, logging library, and redaction helpers; do not import names from a different stack.
- PII is redacted or pseudonymized before it reaches the model. Replace raw records with opaque identifiers, or scrub values matching known sensitive patterns (SSN, email, card numbers, health identifiers). A prompt-level instruction like "don't repeat personal details" is not sufficient.
- No credentials appear in prompt strings. Load them server-side from environment or a secrets manager and never interpolate into a system prompt — even "just for auth context".
- Every return site for an LLM response passes through an output-redaction gate before the response leaves the process. This catches data that leaked in via retrieval or memory.
- If conversation history or a memory/vector store is persisted, records are keyed or partitioned by user identity so one session's context cannot be retrieved by another.
- If prompts or completions are logged, the same redaction helper runs before emission — otherwise logs become the leak.
Verification
Confirm these properties hold for every relevant pattern present in the code under review (each criterion applies only when its pattern is actually present):
- No PII field (SSN, DOB, email, phone, address, health record) reaches an LLM API call site without first passing through a redaction or pseudonymization step
- System prompts contain only constants loaded from a secrets-manager or environment-backed config, never hardcoded credential literals or interpolated secret values — only applies if the code references credentials near the prompt construction
- Every code path that returns an LLM response to a caller routes the response through an output-redaction helper before it leaves the process
- If the code persists conversation history or writes to a memory/vector store, records are keyed or partitioned by user identity so one session's context cannot be retrieved by another — skip when the code is a stateless single-request handler
- If the code contains logging or telemetry statements that receive a prompt or completion variable, the variable is passed through a redaction helper before emission — skip when the code has no logging of prompts or completions