Tenant Isolation
Tenant isolation is the guarantee that one user's books are never visible to another user, enforced at the database layer rather than relying on application code alone.
In short
Not a UI restriction — a database guarantee. Row-level security, forced on every table and keyed to a session-level user id, is what actually enforces this, so an AI connected on one user's behalf genuinely cannot reach another user's books, even through a bug in application code.
Also called: multi-tenant isolation, data isolation
Tenant isolation is the property that keeps every user's books completely separate from every other user's, in a system where many different users' data lives in the same underlying database. In BalanceMCP, this isn't a filter applied somewhere in the application's own code — it's enforced by the database itself, through row-level security.
That distinction matters because of where the guarantee could otherwise fail. An application-level filter — a WHERE clause added in code, a check in a route handler — is only as reliable as every single piece of code that touches the database remembering to apply it. A guarantee enforced at the database layer instead holds even against a bug in the application that forgot to check, or a query written some other way entirely.
Concretely, every table in BalanceMCP forces row-level security, keyed to a session variable set once at the start of a database transaction. Every query, from every tool, transparently only sees rows belonging to the current user's session — there's no code path, buggy or otherwise, that can accidentally return another user's data, because the database itself is what's filtering, not a check layered on top.
A real, current limitation worth stating plainly: there's no sharing or multi-user access on a single book today. Tenant isolation means one user's books are invisible to everyone else — it doesn't yet include a feature for deliberately inviting a second person into the same book.
What people get wrong
- Assuming tenant isolation is a UI-level restriction that a bug could bypass — it's enforced by row-level security at the database layer instead.
- Assuming a superuser or bypass-RLS database role is automatically safe — BalanceMCP deliberately requires connecting as a non-bypass role for row-level security to actually apply.
- Assuming tenant isolation includes deliberate book-sharing between users — it doesn't yet; there's no multi-user access to a single book today.
Common questions
- Could a bug in BalanceMCP's application code expose one user's books to another?
- The guarantee is enforced at the database layer through row-level security, not solely by application code, so it holds even against an application-level bug that forgot to filter correctly.
- Can I share one book with a second user?
- Not today — there's no multi-user access to a single book yet. Tenant isolation currently means each user's books are visible only to that user.
Machine-readable: /api/knowledge/concept:tenant-isolation