Security

Tenant isolation

Every table that holds customer data is protected by Postgres row-level security, not just application-layer checks. Access is evaluated per-row against your organization, workspace, and role membership on every query -- including queries made through the API and MCP server. Isolation is verified by an adversarial test suite that actively attempts cross-tenant reads and writes on every change to the schema, run in continuous integration before any change ships.

Authentication

Application sign-in uses Supabase Auth (email/password, with session refresh handled server-side). Programmatic access uses scoped API keys, stored as salted hashes -- never in plaintext -- and revocable at any time from a workspace's settings.

Least privilege by default

Database functions that perform privileged operations run as a named role with the minimum grant needed for that operation, not as a superuser. Functions intended only for server-side or service callers are explicitly restricted to that role -- they are not reachable from a browser session.

Audit trail

Membership changes, role changes, and review decisions are written to an append-only audit log per organization. Review corrections never overwrite the original extracted value -- they are recorded as an annotation alongside it, so the full history of a value is always reconstructable.

Encryption

Data is encrypted in transit (TLS) and at rest, using the underlying Postgres and object storage infrastructure's encryption-at-rest.

Reporting a concern

If you believe you've found a security issue, contact us through contact sales with details, and we'll follow up directly. See also our compliance page.