One signed binary. Every feature compiled in. Free to run. Install Crowkis →
← back to the Roost
securityJune 27, 2026· 5 min read

Tenant isolation is a feature you test, not a checkbox you claim

Every multi-tenant product says its tenants are isolated. The ones you can trust are the ones that try to break it on purpose. Here's how we prove no tenant can read another's data.

Ask any multi-tenant vendor if tenants are isolated and the answer is always yes. It has to be, it's table stakes. But 'isolated' is a claim until someone deliberately tries to cross the boundary and fails. In a shared semantic cache, where answers are reused across similar questions, the temptation for data to leak between tenants is real and the stakes are a breach.

memory that never crosses lanes
agent · tenant A agent · tenant B agent · tenant C every recall is scoped, no lane can read another’s memory

Every read is scoped to its tenant and user, the walls are enforced, not assumed.

In plain words: In Crowkis, every stored answer and every recalled memory is tagged to its tenant, and the read path enforces the tag. A query from tenant B cannot match tenant A's data, even when the questions are identical.

We test this the way an attacker would think about it: store a fact under one tenant, then ask for it as another. The correct result is nothing, not a filtered-after-the-fact result, but a boundary the query can't cross in the first place. Isolation that's only enforced by remembering to filter is isolation waiting to be forgotten. It has to be structural.

The bottom line

Don't trust an isolation claim; trust an isolation test. Ours says a tenant asking for another tenant's data gets exactly what it should, nothing.