Why bind the tenant filter on RAG retrieval server-side, not in the prompt?

## The rule Authorization decisions belong below the model. A retrieval layer that decides which documents a session may read is making an authorization decision, so it must derive its scope from the authenticated principal, not from anything the model emits. This is the same principle that says a database query must not take its user id from a request parameter the client controls; the LLM is simply a new, unusually persuadable client. ## Three places the scope can live, and only one is safe **In the system prompt.** Telling the model to search only the current brokerage's listings is guidance. It survives ordinary use and fails under adversarial input, and it also fails under plain confusion on a long context. Nothing enforces it. **As a tool parameter.** Exposing a retrieval tool whose arguments include a tenant id or a filter expression looks more rigorous, because the value is now structured. It is not. The model populates it, the model's context contains text from retrieved documents and user messages, and a value the model writes is a value that untrusted text can steer. This shape is common because it is convenient during development, and it is the specific defect an interviewer is usually probing for. **Bound at the query layer.** The retrieval service receives the tenant identity from the session or a signed token, applies it to the query itself, and the tool signature simply has no parameter for scope. The model contributes a search string and nothing else. Now the worst an injected instruction can achieve is a differently worded search inside the same corpus. ## Filtering versus partitioning Binding a filter is the minimum. Stronger is physical or logical partitioning: a separate collection, namespace or index per tenant, selected by the same session-derived identity. The difference matters for two reasons. First, a partition failure is loud, whereas a filter failure is silent and returns plausible results. Second, a partition removes a class of bug where the filter is applied to metadata that ingestion set incorrectly; if the document is not in the tenant's index at all, a mislabelled metadata field cannot expose it. The cost is operational, since many small tenants means many small indexes, and per-tenant partitioning interacts with how the vector store handles memory and index rebuilds. That is a real tradeoff to state rather than wave away. ## Verify at the result boundary After retrieval returns, check that every chunk carries the expected tenant identifier before any of it is placed in the context, and treat a mismatch as an incident rather than a warning. This is not redundant with the bound filter, because it catches a different failure: ingestion writing the wrong tenant on a document, a backfill that dropped the field, or a reindex that lost metadata. Those are ordinary data bugs, not attacks, and they are the most common real cause of cross-tenant leakage in retrieval systems. ## The paths teams forget Scoping the primary query is the easy part. The leaks tend to come from adjacent state that inherited no scope. Caches are the classic case: a semantic or embedding cache keyed on the query text alone will happily serve one tenant's cached results to another, so the tenant identity must be part of every cache key. Reranker and summarization stages that fetch additional context need the same scope. Long-lived agent memory written during one tenant's session and read in another's is the same bug in a different store. Evaluation and trace tooling that replays production retrievals sits outside the request path and often has no tenant concept at all. ## What this control does not do Scoping retrieval per tenant prevents the model from reading data the caller was never entitled to. It says nothing about what happens to data the caller *is* entitled to once it is in the context: that data can still leave through a rendered URL, an outbound tool call or a trace log. Scoping is the containment control that decides how much is at risk; the egress controls decide whether what is at risk can leave. A good answer names both and does not claim either alone is sufficient. ## How to demonstrate it The convincing version of this answer is operational. Show that the tool schema physically has no scope parameter, that the retrieval service reads the tenant from a verified session token, that there is a test asserting a query crafted to request another brokerage's listings returns nothing, and that the result-boundary check exists and is alerted on. An interviewer hears the difference between someone who has configured a filter and someone who has designed the scope to be unreachable from the model.