TL;DR: Walk the pipeline. At ingestion: know who can write each source, copy permissions and tenant into chunk metadata, scan for secrets, and propagate updates and deletions. At retrieval: filter on the asking user's identity before ranking, isolate tenants, key caches by user. At generation: mark retrieved text as untrusted, keep secrets out of prompts, minimise context. At output: safe rendering, citations, no external fetches. Around it: logging with privacy controls, monitoring for poisoning and leaks, and tests for revocation and cross-tenant access.
How to approach it
Clarify scope first: internal or customer-facing, single or multi-tenant, which sources, whether the assistant has tools. Then go stage by stage. Lead with authorization, because missing permission filters cause more real RAG leaks than any exotic attack.
A strong answer
Ingestion
who can write sources
Index
ACL and tenant per chunk
Retrieval
filter before ranking
Generation
context marked untrusted
Output
safe render, citations
Key controls
Secret scan, deletions sync
- Updates propagate with known lag
User-keyed caches
- Tenants isolated in the store
No external fetches
- Blocks exfiltration through rendering
Assume a multi-tenant SaaS assistant answering from each customer's documents and tickets.
Ingestion.
- Source trust. List sources and who can write them. Customer-uploaded documents and inbound tickets are untrusted for instructions.
- Permissions into metadata. Each chunk records tenant, source document ID and allowed principals. Documents whose permissions cannot be represented are excluded.
- Hygiene. Scan for secrets and regulated data; decide what should not be indexed at all.
- Lifecycle. Updates, permission changes and deletions propagate with a defined maximum lag.
Retrieval.
- Tenant isolation. Separate index or namespace per tenant, enforced by the store, not only by application code.
- User filtering before ranking. The query carries the user's principals; only allowed chunks are scored.
- Caches of retrieved context and answers keyed by user and tenant.
Generation.
- Retrieved chunks delimited and labelled as data; instruction-hierarchy model.
- Minimal context: only what the question needs.
- No secrets or access rules in the system prompt.
- If the assistant has tools, apply the lethal trifecta check: retrieved content is untrusted, so outbound capabilities are restricted.
Output.
- Safe rendering: encoded text, no external images, links neutralised or confirmed.
- Citations so users can verify, which also limits harm from poisoned content.
Operations.
- Logs that record retrieval sets and answers with redaction and short retention.
- Monitoring: denied cross-tenant access attempts, documents that suddenly dominate retrieval, outbound URLs in answers.
- Tests: a revoked user cannot retrieve; tenant A cannot retrieve tenant B; deleted documents disappear; an injected test document cannot trigger exfiltration.
Weak RAG
Search runs as service
all documents
Answer renders images
from any URL
Cross-user leaks
Outcome, unsafe: Exfiltration via render
Poison unnoticed
Secured RAG
Filter by user before ranking
ACLs on chunks
Safe markdown, no remote images
citations
Only permitted content
Outcome, safe: No render channel
Provenance tracked
What interviewers probe next
- "Filtering after top-k is simpler. Why not?" Relevance collapses when many top results are forbidden, and teams then loosen filters. Filter inside the search.
- "What about embeddings themselves?" Embeddings can leak information about source text, so protect the index like the documents it was built from.
- "How do you handle a shared knowledge base plus private documents?" Two scopes in the query, each with its own permission filter, and clear source labels in answers.
What if?
What if · interview follow-ups
Hold your answer as the constraints change
You are reviewing a RAG assistant design from document ingestion to the rendered answer, before it is opened to all employees.
Start here
What would you check at ingestion?
What must be attached to each chunk for later checks?
Who can write each source and therefore who can influence answers; that document permissions are captured with each chunk; parsing of risky formats in a sandbox; detection of hidden text and instruction-like content; removal of secrets; and provenance (source, author, time) stored with every chunk.
Carry it forwardIngestion decides who can influence answers and what permissions travel with data.
Weak answerTreating ingestion as a pure data-engineering task.
Constraint changes
What if retrieval runs with a service account that can see everything?
Whose access does the search use?
Then any user can get any document's content into their answer by asking the right question. Retrieval must filter by the requesting user's permissions, using permissions synced from the source system and checked at query time, with tests that confirm users cannot retrieve what they cannot open.
Carry it forwardRetrieval must enforce the asker's permissions.
Weak answerRelying on the model not to mention restricted content.
Constraint changes
What if the model can call tools after reading retrieved text?
Who can write the text the model reads before acting?
Then retrieved documents can steer tools, so anyone who can edit a document can try to act through the assistant. Keep tools narrow and user-scoped, separate retrieval-heavy answering from actions, and confirm high-impact actions.
Carry it forwardRetrieved text plus tools is an injection path.
Weak answerAdding tools without reconsidering who writes the documents.
Constraint changes
What if answers render markdown and citations?
What can a rendered answer make the browser do?
Rendering can exfiltrate through images and links, and citations can point to attacker URLs. Sanitise output, block remote images, show citation destinations and verify that cited documents are ones the user can access.
Carry it forwardThe rendered answer is an output channel to secure.
Weak answerSecuring retrieval and forgetting rendering.
Constraint changes
What if a user reports an answer containing data they should not have seen?
Could you reconstruct what was retrieved and why?
Treat it as a potential breach: preserve the session's retrieved chunks and permissions at the time, check whether the permission sync was stale or a filter was missing, and search for the same pattern across other sessions. Provenance in logs makes this possible.
Carry it forwardLog retrieved chunks with permissions to investigate leaks.
Weak answerAnswering 'the model hallucinated' without checking retrieval.
Now defend it
What does your review report recommend?
Permissions and provenance on every chunk; sandboxed parsing with hidden-text detection and secret removal; retrieval filtered by the asker's current permissions with negative tests; narrow, user-scoped tools separated from answering and confirmed for high-impact actions; sanitised output without remote images and with visible citations; and logs of retrieved chunks to investigate reported leaks.
How it's scored
Weak: Focuses on prompt instructions and an input filter; access control is mentioned vaguely.
Hire: Copies permissions into metadata, filters by user, isolates tenants and treats retrieved text as untrusted.
Strong Hire: Covers lifecycle sync and deletion, caches, output handling, the trifecta for tool-using variants, and gives a concrete test plan.
Common mistakes
- Indexing everything first and planning permissions later.
- Tenant filters implemented in one code path that another path skips.
- Ignoring deletion and revocation latency.
- Sharing a response cache across users.