The full answer
Treat it as a data breach first and a bug second: contain it, find every place the two customers' data could meet, and fix it with access checks in code, not instructions in the prompt. A model does not leak data it never received. If another customer's details reached the answer, some part of your system put them in the request: retrieval, a cache, shared memory, a tool call or the conversation history.
1. Contain
- Turn off the feature or the suspected path (retrieval, memory, caching) while you investigate.
- Preserve the traces and logs for the affected conversation.
- Bring in security and privacy people early. Depending on the law that applies, a leak of personal data can have a deadline for notifying the regulator and the people affected.
2. Find how the data got in
Open the full trace of the bad answer and find where the other customer's data first appears in the request. Then check the usual paths:
| Path | How it leaks |
|---|---|
| Retrieval | The vector search has no tenant filter, or applies it after taking the top results, so another customer's documents come back |
| Application cache | A response cache keyed on the question text alone serves one customer's answer to another who asked the same thing |
| Memory or session state | A shared memory store, or a session id reused across users, mixes conversation history |
| Tools | A tool takes customer_id from the model's arguments instead of the logged-in session, so the model can request anyone's data |
| Logs and examples | Real conversations copied into prompts as few-shot examples or into a fine-tuning set |
Prompt caching on the Claude API is not one of them: a cache hit needs an identical prompt prefix, caches are isolated per workspace, and the cache stores the model's processing of your prompt, not an answer to replay. Your own response caches are a different matter.
3. Fix it in code
- Filter by tenant inside the query. Every retrieval call includes the customer or tenant id as a filter the database applies before ranking. Better still, separate indexes or namespaces per tenant for sensitive data.
- Take identity from the session, never from the model. Tools read the user from the authenticated request. The model chooses what to do, not whose data it can see.
- Key every cache by user or tenant, and do not cache answers built from personal data.
- Scope memory per user, with an explicit owner on every record.
- Redact or mask personal data before it goes into logs, examples and training sets.
A system prompt line such as "never reveal other customers' data" is not a control. It can be ignored or bypassed through prompt injection, and the model cannot know which data belongs to whom.
4. Prove it stays fixed
Add tests that log in as customer A and try to reach B's data by every path: direct questions, crafted queries that match B's documents, tool calls naming B's id. Run them on every release, and alert on any retrieved document whose tenant does not match the request's.
What interviewers want: treating it as an incident, tracing where the data entered the request, the specific leak paths (retrieval filters, caches, memory, tool identity), enforcing access in code rather than the prompt, and cross-tenant tests.
Last updated 16 October 2026
Sources