Multi-Tenant AI Over Databases: How We Keep One Customer's Question From Touching Another's Data
In a multi-tenant AI platform, the failure mode isn't a wrong answer. It's the right answer from the wrong company's data. Here's how Cazper makes that impossible.
Most conversations about AI accuracy focus on whether the answer is correct. In a multi-tenant platform, there's a worse failure than a wrong answer: a correct answer computed from data that belongs to someone else.
If your NL-to-SQL tool serves many companies, isolation isn't a feature. It's the foundation everything else stands on. Here's how we think about it, and how Cazper enforces it.
Isolation has to hold at every layer, not just the login
It's easy to isolate the front door: authenticate the user, show them their dashboard. The hard part is that a single natural-language question travels through many layers, and each one is an opportunity to leak:
- The connection: which database does this query actually run against?
- The context: which schema, business rules, and synonyms get loaded to help generate the query?
- The execution: whose data does the result set come from?
- The history: which prior conversation turns inform this follow-up?
A tool that scopes the login but not the context lookup can still bleed one customer's schema descriptions into another's session. Isolation is only as strong as its weakest layer.
Every operation is scoped to the authenticated tenant
Cazper's architectural rule is blunt: every query, every context lookup, and every database connection is scoped to the authenticated user's tenant. Not filtered after the fact. Scoped at the point of access.
Tenant identity is established at authentication and carried through the request. When Cazper resolves which database to connect to, it resolves within the tenant. When it loads business context to help write the query, it loads that tenant's context. When it fetches conversation history for a follow-up, it fetches that user's history. There is no code path where a tenant identifier is optional.
No cross-database context leakage
There's a subtler leak than data, and that's context. The schema descriptions, column synonyms, and business rules that make one customer's database queryable are themselves sensitive. They describe how that company models its business.
So per-database context is walled off. The metadata that helps generate a query for Database A never enters a session for Database B, not even within the same tenant, let alone across tenants. Each database's session sees only its own context. This keeps answers correct, with no phantom columns from the wrong schema, and it keeps proprietary data models private.
Audit makes isolation provable
Isolation you can't prove is isolation you're asking customers to take on faith. Every database operation Cazper performs is logged with the user ID, tenant ID, database ID, and timestamp. If anyone ever needs to demonstrate that a given query ran against the correct tenant's data, whether for a security review, a compliance audit, or an incident, the record exists.
That turns "we isolate tenants" from a claim into something you can point at.
Why this is non-negotiable
We treat cross-tenant access the way a bank treats moving money between the wrong accounts: not a bug to be patched later, but a class of thing the system is built to make impossible. Multi-tenancy is easy to bolt on and nearly impossible to retrofit safely. Building it into the foundation, with scoped connections, walled context, and per-operation audit, is the only version that holds up when it matters.
For an enterprise evaluating AI over its database, that foundation is the first question worth asking. It's the one Cazper was designed to answer.
