Tenant isolation as physics, not policy
A WHERE clause is a promise; a namespace is a wall. How Crowkis makes cross-tenant leakage structurally impossible rather than procedurally unlikely.
Most multi-tenant data leaks share an autopsy: isolation was implemented as filtering — a tenant_id predicate that one code path, one day, forgot. Policy-based isolation fails open under bugs. The alternative is structural: make tenant identity part of the key itself, so a cross-tenant read isn't forbidden — it's unexpressible.
Crowkis namespaces every entry by tenant at the storage layer; lookups operate within a namespace because there is no cross-namespace lookup to call. Then the write path adds the unusual second layer: isolation is a scored stage in the trust pipeline, so an entry whose characteristics suggest boundary confusion is refused before it exists. Leak prevention happens at write time, where it's cheap, not read time, where it's a breach.
Five stages score every write before it can ever be served.
Deliberate sharing stays possible because it's explicit: platform-wide content lives in a designated shared tenant by choice, not by accident. The dashboard accounts per tenant, budgets gate per tenant, and Enterprise audit logs trace per tenant — the boundary is the organizing principle of the whole control plane.
The bottom line
Caches see every question every customer asks, which makes them the most concentrated multi-tenant risk in an AI stack. Build the wall into the physics and the WHERE-clause genre of incident simply has nowhere to happen.