Sensitive Information Disclosure (OWASP LLM06:2025)
SkillAI & modelsDetects PII, credentials, and secrets passed to LLM APIs or embedded in system
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Sensitive Information Disclosure (OWASP LLM06:2025) skill
What this skill tells your AI
The instructions your AI receives, as published by thejefflarson/soundcheck in .claude/skills/sensitive-disclosure/SKILL.md and read by ahel’s review.
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
References
Signals
- GitHub stars
- 20
- Last commit
- Jul 2026
Advanced
- Catalog kind
- skill
- Gateway key
sensitive-disclosure- Source
- github.com/thejefflarson/soundcheck