Why isolation between organizations has three layers

One organization's document showing up for another is the single fatal risk of this product. Application bugs are inevitable; we did not want a defense that depends on flawless code. The decision: three layers independent of each other. A leak requires all three to fail at once.

The first layer is the application. The gateway takes the tenant only from the verified identity token; never from the request body or a header. Internal calls carry the tenant explicitly; every handler asks for the tenant from the context and rejects the request if it is missing.

The second layer is the database. Every tenant-owned table has a row-level security policy, enforced for the table owner too. Every request transaction is opened through a single path that writes the tenant into a session variable. If a query forgets the tenant condition, the policy still filters.

The third layer is search. Every tenant has its own vector collection and its own search index. Even if the wrong permission filter is sent, another tenant's data is not in that collection.

How we check: four integration tests for the database layer run on every release and must be green. For the permission filter, an automated fuzz test generates thousands of queries against the real engines; a single leak stops the release. The last full run: 2,010 queries, 0 leaks.

When we would change it: past a few hundred tenants, the operating cost of separate indexes grows. On that day we re-evaluate filter-based isolation with contract tests. Not today.