Every chunk of text, and every tool call, carries the tenant it belongs to. Search filters on that key before the model sees a document. A tool refuses to run if the signed-in user is not in that tenant.
Products already separate customers in one of three ways. Row-level security keeps everyone in one database and lets a policy hide other rows. A schema gives each customer their own set of tables in the same database. A silo gives a customer their own database or store. We stay with the pattern your app already uses.
Before launch we try the obvious failure: a user from one tenant asks for another tenant’s file, and a tool call tries to act on the wrong account. Both have to fail.
The service this supports is RAG for a multi-tenant product, which is part of AI features for SaaS.
One database. A policy hides every row that is not this tenant’s.
Each customer has their own tables in the same database.
A customer has their own database or store.
This is the pattern we follow. It is not a picture of a client’s system.
The one your product already uses. Changing it just for the AI feature is a bigger project than the feature.
No. It is the pattern. We do not publish a client’s architecture.
