Isolation is enforced beneath the query, not inside it.
Tenant, brand, workspace and region are bound to the database client an endpoint receives. An endpoint author cannot widen the boundary by writing a different where clause, because the boundary is not expressed in their clause. That is the whole security posture in one sentence — the rest of this page is how each layer does it, and what we have not finished.
We hold no attestations. Here is what we have instead.
Plenty of vendors put a row of green “Compliant” badges on this page. A badge is a claim about paperwork, and your security team will ask for the report behind it within one email. So: no certifications, stated plainly, and the engineering underneath described precisely enough to be checked.
Four nested boundaries, four different mechanisms.
Deliberately different, so that a failure in one does not collapse the others. Each row names what would go wrong if that boundary were bypassed — which is the only honest way to describe a control.
| Boundary | Mechanism | Failure mode if bypassed |
|---|---|---|
| Tenant | Every query carries the tenant predicate, bound to the client before an endpoint sees it. | One customer reads another customer’s data. |
| Brand | A Prisma client extension that filters reads and stamps writes across 179 registered models. | One operating company sees another’s contacts, pipeline or campaigns under the same contract. |
| Workspace | The same extension, applied additionally to the 11 models where location is a real distinction. | A location sees another location’s working data. |
| Region | US, EU and ASIA are separate databases with separate audit chains. No cross-region join exists anywhere in the system. | A residency violation — structurally prevented, because no query can span two databases. |
Brand data lives in the region of its enclave. Identity data lives in the account’s home region. If your account is registered in the US and you operate a brand in the EU, that brand’s contacts, campaigns and analytics are in the EU database and never leave it — but the user records, sessions and access grants for the people who administer it remain in the US. An earlier version of this page said EU data “never touches US infrastructure”, which was true of the brand data and not true of the identity data. If that distinction matters to your regulator, register the account in the region you need, and talk to us before you build around it.
Standing eligibility. On-demand privilege.
Access is granted as a policy over a role and a scope — account, enterprise, brand or workspace — and a person’s effective access is the union of their grants. Two separate clocks govern each one, and conflating them is the failure this design exists to prevent.
There is no expiry job. Liveness is computed when a grant is read, so an activation lapses because the clock passed, not because something ran. A scheduled job that fell over would otherwise leave elevated privilege standing — which is the exact failure this pattern removes. It cannot fail open.
expiresAtactivatedUntilChained, checkpointed, exported.
Every grant, revoke, disable and policy change writes an entry that hashes the one before it. A daily job records each region’s head hash and entry count, and a second job writes that day’s entries to storage under an immutability policy with the hash of the exported bytes — so the chain in the database can be checked against a copy neither side can quietly rewrite.
Stated honestly: chaining is asynchronous, so there is a short window in which the most recent entries are not yet chained. That is a deliberate trade — hashing must never block a business operation — and it is documented rather than papered over.
Probes against real databases.
Isolation claims are not asserted in a document — they execute against real regional databases on every change. The suite covers scope resolution and grant union, cross-brand data isolation, the full 179-model closure, analytics rollup authority, brand domain resolution, the identity gate, SCIM, and referential integrity.
The architecture document ends with the open items — the places raw SQL sits outside the automatic brand filter, the asynchronous audit window, where multi-factor is enforceable but not yet required, what pod isolation does and does not mean today, and the absence of an external assessment. A security document that lists only what works is a sales asset, and a technical reviewer reads it as one. Ask for it under NDA and you get the same list we work from.
What we can share.
Send us the hard questionnaire.
The one with the questions vendors dodge. Some of our answers will be “not yet” — you will be able to tell which, and that is the point. Email security@borakdesk.com with your form, your NDA, or a request for the architecture document.
Email the security team