Zenaique

Walk through the three production paths through which LLM06 (sensitive disclosure) typically leaks

Flashcard·Medium·4.0 · 0·~30s·Asked atRazorpayReplicateUipath
Attempt it
TL;DR

LLM06 leaks via three paths: model output (caught by output rail), cross-tenant context via retrieval or prompt cache, and telemetry export to third-party observability.

Memory aid
Sign in to see the mnemonic that makes this stick.
Easy to grasp

Imagine a hospital that wants to keep patient records private. The obvious risk is a nurse reading the chart out loud in the waiting room. But two quieter risks exist. A clerk accidentally hands one patient's folder to a different patient because the folders sat in a shared bin. And the security cameras record everything that happens at the front desk, including charts being read aloud, and the footage gets sent to an off-site company for archiving. Hospital privacy is only as good as the weakest of those three paths. LLM data disclosure works exactly the same way. Most teams fix the loud reading but never check the shared bin or the off-site recording.

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

OWASP LLM06, Sensitive Information Disclosure, is the OWASP item where production teams most often think they are covered and are not. The standard mental model is 'add a PII detector to the output rail.' The actual production reality is that sensitive data leaks through three paths, of which the output rail covers only one. Multi-tenant retrieval bugs and telemetry export pipelines account for the majority of post-incident LLM06 findings in 2026.

This walkthrough names each path, explains the failure mode and the fix, and frames the defense in depth posture that closes all three. The principle: every place the system processes sensitive content is a potential leak path; the rail must exist at each one, not just at the loudest.

Mental model: LLM06 leaks at three points: out of the model, into the model, and aside through telemetry. Patching only the first one is the most common production mistake in this category.

Path one: the model emits sensitive content in its response

What happens

The model generates a response. The response contains a phone number, an email address, a credit card snippet, a person's name where it should not be, or a paraphrase of confidential text from training data or context. The user receives the response and the disclosure has happened.

Where the content comes from

Four common sources:

  • Training data. The model memorised content during pretraining and is now reproducing it in response to a probe. Famous in 2021 with the GPT-2 training-data extraction work; less common in 2026 but still possible for verbatim memorised content.
  • System prompt. Sensitive content baked into the system prompt (API keys, internal URLs, customer-specific instructions) leaks via a system-prompt extraction attack.
  • Retrieval context. Documents fetched for RAG contain PII that the model summarises into the response.
  • User input. The user supplies the PII themselves in their prompt, and the model echoes it back.

The defence

This is the path the standard output rail covers:

  • A PII detector (regex for high-confidence patterns, Microsoft Presidio for named entities, model-based detectors for fuzzy categories) runs on the response.
  • Detected spans are replaced with redaction markers ([REDACTED], [PHONE], etc.).
  • The unredacted value goes to an access-controlled audit log for forensics.
  • The redacted response flows to the user.

Bedrock Guardrails, Azure AI Content Safety, Llama Guard 4 with custom taxonomy extensions, and self-hosted Presidio are the canonical implementations. Most production teams have this layer; it is the easiest of the three to deploy.

Path two: cross-tenant context contamination
Path three: telemetry export to third-party observability
Defense in depth across all three paths
Sign in to unlock the full deep dive.

Situations where this technique stops working.

Sign in to see when this approach fails.

2–4 min · Everything important, quickly.

Sign in to see the quick scan of the deep dive.

Real products, models, and research that use this idea.

  • Pinecone, Weaviate, and Qdrant 2026 all ship tenant-scoping primitives (namespaces, multi-tenant collections) explicitly motivated by LLM06 retrieval-bug incidents documented in their case studies.
  • Anthropic's prompt-caching documentation calls out tenant isolation in cache keys as a required engineering practice for multi-tenant SaaS using Claude Opus 4.7.
Sign in to see more production examples.

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you test that your retrieval pipeline actually enforces tenant isolation under load?
A

Negative integration tests: explicitly query for documents that should NOT match (other-tenant documents indexed for the test) and assert empty results. Run under load to expose race conditions in namespace resolution. Combine with chaos testing that injects bad tenant identifiers and asserts the API rejects rather than falls through to default.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Focusing entirely on the model-output rail and assuming the retrieval pipeline and the observability stack are 'inside the trust boundary', both are common LLM06 leak paths in production.

Sign in to see all red flags and common mistakes.

60 second bullets to scan on the way to the call.

  • The three production leak paths for LLM06 (output, context, telemetry)

  • Why the output rail does not cover paths two and three

Sign in to unlock the revision sheet.

Primary sources. Browse if you want the original framing.

Similar questions

Same topic, related formats. Practice these next.

4 curated
Next question
Pick the strongest reason…
MCQ·Medium