Security
What's true today, stated plainly.
This page lists what's actually built and enforced right now. For anything we haven't gotten to yet, we say so below instead of leaving it ambiguous.
Role-based access
Every member has a role — owner, admin, or member — checked on the server before any write, not just hidden in the UI.
Row-level tenant isolation
Every table carries an organization_id and a Postgres row-level security policy scoped to it. Isolation is enforced by the database itself, not just application code.
Cited, not asserted
When the assistant answers from your documents, it names the source. There's no answer that claims to be grounded without something to point back to.
Rate-limited usage
A daily request cap is enforced in the database itself, so a runaway loop or a bug can't quietly run up an unbounded model bill.
Authentication via Supabase Auth
Passwords are never handled or stored by our own code — sessions and credential hashing are delegated to Supabase's auth system.
Encrypted in transit
All traffic — app, API, and database connections — runs over TLS.
Not built yet
- — Knowledge is shared workspace-wide — there's no per-document permission model yet, so nothing is filtered by who's asking within an org.
- — No SOC 2 audit has been completed. It isn't claimed anywhere in this product.
- — No dedicated per-organization database — tenants share infrastructure, isolated by row-level security rather than physical separation.
- — No IP allowlisting or audit-log export yet.