Security and tenant isolation

Isolation here is a database property, not an application convention. What follows is the mechanism, named specifically enough that you can ask us to demonstrate any part of it.

Row-level security, enforced and forced

Every tenant-scoped table has PostgreSQL row-level security enabled and forced. Enabled means the database evaluates a policy on every read and write. Forced means the policy applies to the table's owner as well - without it, the owning role bypasses every policy silently, which is the failure mode that makes an otherwise correct isolation story untrue in production.

The predicate is evaluated by the database on each statement. It is not a WHERE clause the application remembers to add: a query that forgets the filter returns nothing rather than returning another tenant's rows.

Per-tenant scoping on every tenant-scoped table

Every tenant-scoped table carries a tenant_id column, and it is the column the row-level security policy reads. The tenant is established once, at the edge, from the authenticated session - never from a request parameter, a header, or a subdomain a caller controls.

Tables that carry no tenant dimension - platform infrastructure such as process liveness - hold no grant at all rather than an unpoliced grant. There are two states here and no third: a table is either unreachable by a tenant role, or it is scoped and policed.

Support access is audited and time-boxed

When our staff need to see a workspace to answer a support case, that access is impersonation with an audit record and an expiry. Every session is attributed to the named staff member who opened it, records the tenant and the reason, and ends automatically - it does not persist until somebody remembers to close it.

The audit record is written on the way in, not derived afterwards from logs, so the question "who looked at this workspace, when, and why" has an answer that does not depend on log retention.

The data processing agreement and subprocessors

Our Data Processing Agreement is published in full, with its subprocessor list and a version hash, alongside the Terms, Privacy Policy, Acceptable Use Policy and SMS and A2P disclosure. We hold no security certification today and this page claims none: the Terms say our controls are not a certification, and a badge here that the Terms disclaim would be worth less than saying so plainly.

What we will show you

A diligence reviewer can ask for the policy definitions on any tenant-scoped table, the audit schema behind support access, and the subprocessor list as published. Everything on this page is a thing that can be demonstrated rather than asserted, which is the entire difference between this page and the word "structural".