TL;DR: Follow one sensitive value: it is copied into the prompt, sent to the model provider, written to logs and traces, cached, stored in conversation history and memory, possibly added to evaluation and fine-tuning sets, and possibly memorised in weights. It can leak from any of those, or through the answer to the wrong user via retrieval without authorization. Fix retrieval authorization and logging first, because they cause most real incidents, then minimise, scope and expire every other copy.
How to approach it
Use the "follow the data" method rather than a memorised list; it is easier to make complete and it shows reasoning. Then prioritise. Interviewers check both breadth and judgment.
A strong answer
Prompt
copied in
Model provider
sent out
Logs and traces
written down
History, memory
stored for later
Eval and tuning
maybe in weights
Wrong-user answers
Retrieval without authorisation hands it to someone else
Following a customer's account number through the system.
| Copy | Leak path | Control |
|---|---|---|
| Prompt and retrieved context | Shown to another user if retrieval ignores permissions | Authorization before retrieval |
| Model provider | Retained or used under the provider's terms | Contract: no training, retention limits, residency |
| Logs and traces | Broad internal access, third-party observability vendors, long retention | Redact; separate content logs; restrict and expire |
| Response and context caches | Served to the wrong user | Key by user and tenant |
| Conversation history | Reloaded into later prompts; visible to support staff | Scope per user; retention policy |
| Memory | Persisted and reused, possibly across sessions | Typed, user-visible, deletable |
| Eval and fine-tuning sets | Copied into datasets with weaker controls | Consent and de-identification; dataset access control |
| Model weights | Memorised, extractable by any user of the model | Keep sensitive data out of training |
| Answers and rendering | Injection-driven disclosure; exfiltration through images and links | Minimal context; safe rendering; egress controls |
| System prompt | Credentials or internal details | No secrets in prompts |
Priorities. Most incidents in practice come from two places: retrieval or tools returning data the user should not see, and logs that copy everything to systems with weaker controls. Fix those first, then reduce copies: retrieve less, log less, keep less, and never train on what you might need to delete.
Ownership. Data protection obligations follow every copy, so each processor (model provider, observability vendor) needs to be in the data map and the deletion process.
What interviewers probe next
- "Support wants full transcripts for debugging." Give them redacted transcripts by default and audited, time-limited access to full ones for specific cases.
- "How do you handle a deletion request?" Delete from history, memory, caches, logs and datasets; document model-weight exposure if the data was trained on.
- "How do you detect leakage?" Canary records, cross-tenant access alerts from authorization denials, and output scanning for known secret formats.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
A legal team uploads contracts to an LLM feature that summarises them, using a third-party model provider.
Start here
Where does a contract's text go after upload?
List every system the text touches on its way to the summary.
To more places than people expect: object storage for the upload, the text extraction service, possibly an embedding service and vector index, the prompt sent to the provider, the provider's logs and abuse monitoring, your own application logs and traces, caches, analytics tools, and any human review queues. Each copy has its own access, retention and region.
Carry it forwardMap every copy of the data, including logs and caches.
Weak answerThinking only about the model provider.
Constraint changes
What if logs capture full prompts for debugging?
Who can read the logging system?
Then confidential contract text sits in the logging system, often with broader access and longer retention than the documents themselves, and possibly in third-party observability tools. Log references and metadata, redact or sample with short retention, and restrict access.
Carry it forwardDebug logs often leak more than the product does.
Weak answerLogging full prompts by default.
Constraint changes
What if the provider's terms allow using data for training?
What does the contract with the provider say about your data?
Then confidential contracts may influence future models and be visible to the provider's staff or processes. Use plans or settings that exclude your data from training, confirm retention and abuse-monitoring terms, region and sub-processors, and record the decision.
Carry it forwardProvider terms are part of the data flow.
Weak answerAssuming enterprise defaults without reading the terms.
Constraint changes
What if retrieval serves one client's contract in another client's summary?
What separates one client's documents from another's?
That is a confidentiality breach between clients, likely from missing matter or client-level access controls in retrieval or caching. Enforce matter-level permissions in retrieval and cache keys, and test with canary documents.
Carry it forwardClient and matter boundaries must be enforced in retrieval and caches.
Weak answerRelying on users to upload to the right place.
Constraint changes
What if a user asks for a document to be deleted?
How many copies did your map find?
Deletion must reach every copy: storage, extracted text, embeddings, caches, logs where possible, and provider-side retention. Map this before launch so deletion is a procedure, not a search.
Carry it forwardDeletion is only real across all copies.
Weak answerDeleting the uploaded file only.
Now defend it
What data controls would you require for this feature?
A data-flow map of every copy; provider terms with no training on your data and known retention, region and sub-processors; matter-level access in retrieval and caches; logs with references instead of full text, short retention and restricted access; encryption; a tested deletion procedure across all copies; and canary tests for cross-client leakage.
How it's scored
Weak: Mentions only the answer leaking through injection.
Hire: Lists most paths with controls.
Strong Hire: Uses a follow-the-data method, prioritises retrieval authorization and logging, includes processors and deletion, and proposes detection.
Common mistakes
- Forgetting logs and traces, often the largest copy.
- Treating the model provider as part of your own boundary.
- Fine-tuning on production conversations without consent or de-identification.
- No plan for deletion across copies.