Access built on
deny-by-default.
Compass uses four-role RBAC — Owner, Admin, Manager, Employee — backed by deny-by-default row-level security and org-scoped data isolation. An approval inbox gates role elevation. An append-only audit log records every significant action. Access has to be earned and granted — it is never assumed.
Deny-by-default RLS enforced at the database layer. Org data never bleeds across tenants. Audit log is append-only — no row is deleted.
Security that lives in the data layer, not the UI
Most apps trust the UI to enforce access. Compass enforces access at the database layer — deny-by-default row-level security (RLS) means that even if a UI bug surfaces a button, the data query returns nothing unless the role is explicitly authorized. Org isolation is structural. There is no configuration switch that could accidentally expose one org's data to another.
What each role can — and cannot — do
The matrix below shows exactly which capabilities each role has access to. Partial access (∼) means scoped to own data only — a manager can view team data, not cross-team. This is enforced at the data layer.
| Capability | Owner | Admin | Manager | Employee |
|---|---|---|---|---|
| View own data (KPIs, Report Card, tasks) | ✓ | ✓ | ✓ | ✓ |
| View team data (aggregate) | ✓ | ✓ | ✓ | — |
| Drill down individual Report Cards | ✓ | ✓ | ∼ | — |
| Manage members (invite, remove) | ✓ | ✓ | — | — |
| Bulk CSV invite | ✓ | ✓ | — | — |
| Approve Admin role requests | ✓ | — | — | — |
| Configure org settings & KPI definitions | ✓ | ✓ | — | — |
| Upload actuals (CSV) | ✓ | ✓ | ∼ | — |
| Read audit log | ✓ | ✓ | — | — |
∼ = scoped to own team or data only, enforced at data layer. ✓ = full access for role. — = denied by RLS policy.
These permissions are enforced by Supabase RLS policies at the database layer — not just checked in application code. A UI bug cannot expose a row a role is not authorized to see. Org isolation is structural: every query filters on org_id = auth.jwt()->'org_id' as a hard policy condition.
Four steps from invite to auditable access
Admins invite members via the UI or by uploading a CSV with name, email, and initial role. Bulk invites process asynchronously — each invited member receives a scoped invitation email. No member is added to the org without an explicit invite action.
Admin role requests and certain elevated-access requests land in the Owner's approval inbox. They do not take effect until explicitly approved. Every approval and rejection is written to the audit log with timestamp and approver identity.
Once a member is active, their queries are filtered by RLS policies that check role and org_id on every request. Cross-org data is structurally inaccessible. Role downgrades take effect immediately — no cache, no delay, no session to wait for.
Every significant event — invite, approval, role change, data upload, audit log read — is written to the audit log. Rows are append-only: no update, no delete. Owners and Admins can read the full log for their org at any time.
Architecture, not configuration
Security properties that require correct configuration by every admin are security properties that will eventually be misconfigured. Compass puts the guarantees in the architecture so they are not dependent on correct usage.
Invite. Approve. Audit.
Admin & Security is live in Compass. RBAC, deny-by-default RLS, org isolation, the approval inbox, and the append-only audit log are active from the moment your org is set up — no configuration required.