Tenant isolation and access control

Row level security

Every table in Kabaido carries an organisation id, and the database itself enforces row level security policies over it. A query from your session can only ever see rows belonging to organisations you are a member of. This is not an application filter that a bug could skip: the policy runs inside the database on every read and write.

Write policies are role ranked. Editing the catalogue needs the engineer role or above, managing integrations and settings needs admin or above, and billing is owner only. The same checks gate the interface, but the database is the authority.

Storage isolation

Uploaded files, generated documents, logos and import files live in storage buckets where every path begins with the owning organisation's id. The storage policies parse that prefix and apply the same membership and role checks as the database tables, so a file belonging to one organisation is never reachable from another.

Roles

Five roles cover the platform: viewer, sales, engineer, admin and owner. The full capability matrix is on the Users, roles and permissions page in Getting started. Owner safeguards prevent the last owner being demoted or removed, and only an owner can grant ownership.

Elevated access on the server

A small number of server side jobs run with elevated database credentials because they act before or outside a user session: payment webhooks, import workers, the AI pipeline, scheduled jobs and the public quote portal. Each is confined to queries scoped to a single named organisation, and the elevated key is never exposed to the browser.

Audit logging

Administrative actions are written to an audit log with the actor, the action and the before and after values, including bulk catalogue edits and operational changes to accounts. Service items additionally record every status transition as an event with its actor, so approvals, rejections and overrides can be traced after the fact.