How do LLM applications leak sensitive information, and how do you prevent it?

Sensitive information disclosure is consistently one of the top LLM risks because models touch a lot of data and have several distinct leak paths.

How leaks happen

• Training-data memorization. Models can memorize and regurgitate verbatim chunks of their training or fine-tuning data — PII, credentials, internal documents — when prompted in the right way. This is a model-level risk that's hard to undo after training.
• System-prompt leakage. Apps often stuff instructions, business logic, and sometimes secrets into the system prompt. Attackers extract it via injection. Treat the system prompt as readable by users.
• Over-permissioned retrieval. In RAG, if the vector store returns documents without checking the asking user's authorization, the model will happily summarize data they were never allowed to see.
• Cross-session / cross-tenant bleed. Poor isolation, shared caches, or reused context can leak one user's data into another's response.

Prevention

• Data minimization before training and fine-tuning; scrub PII and secrets from corpora.
• Never put secrets in prompts. Keep keys and credentials in a secrets manager, fetched server-side with least privilege.
• Authorization at retrieval time. Filter the vector store by the requesting user's permissions, not after the fact.
• Output filtering and PII redaction on responses.
• Tenant isolation for context, memory, and caches.

What interviewers look for

A candidate who enumerates multiple leak paths — not just "the model says secret things" — and matches each to a concrete control, especially per-user authorization on RAG and keeping secrets out of prompts.