The leak problem
Welcome. In this course you build a role-gated RAG chatbot. Three roles (finance, engineering, admin) share the same UI, but each one only ever sees the documents they are allowed to see. We start with a concrete leak scenario so the whole design makes sense before you look at the code. All the code lives at github.com/learnwithparam/rbac-rag-chatbot.
Picture a shared chatbot at a mid-sized company. Finance uploads the Q3 report. Engineering uploads a postmortem about a last-minute security patch. One day a finance analyst asks "summarize our Q3 performance". The vector store embeds the query, runs a similarity search, and the top result is the postmortem because both docs discuss "Q3 issues". The model answers using engineering content finance should never have seen. The UI never misrouted anything. The retrieval did.
Where the leak happens
The retrieval step is the real access boundary. The UI can do everything right and still leak if retrieval sees all documents.
The lesson is subtle: the vector store is the real access boundary, not the login form. A role claim in a JWT does nothing if the code that runs similarity search does not read the role. The fix is to make retrieval itself scoped by role, so a finance query literally cannot touch engineering documents.
Quiz: Quiz
Loading practice…
Once retrieval is the boundary, every other layer becomes easier. Auth still matters, rate limiting still matters, the admin panel still matters, but none of them are the last line of defense. We can design each one for the right reason instead of stretching it to paper over a leaky store.