sensitive-disclosure
Detects PII, credentials, and secrets passed to LLM APIs or embedded in system prompts. Use when writing code that passes sensitive data (PII, credentials, health data) to an LLM API, constructs syste
Files1
View on GitHubSKILL.md.claude/skills/sensitive-disclosure/SKILL.md
GitHubSensitive 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