Skip to main content

Security And Scoping

SABLE uses layered controls rather than a single trust boundary.

Browser Boundary​

The browser never receives service-role secrets or connector API keys. It calls Vercel API routes with a Supabase user session.

Viewer Resolution​

web/api/_auth.js verifies the Supabase JWT and resolves the user to a people row:

  • id
  • org_id
  • name
  • role
  • email

Admin and lead users are treated as leads by isLead.

Service-Role Caution​

Server routes and Edge Functions often use a service-role Supabase client. That bypasses RLS, so every query must scope explicitly by org_id and project membership.

Role Gates​

  • Read routes require a valid viewer when Supabase is configured.
  • Approval mutation requires admin/lead.
  • Edge connector runs require admin/lead JWT unless they are signed public webhooks.
  • Asana execution requires admin/lead plus ASANA_ACT_WRITES_ENABLED=true.

Document Rules​

Restricted documents are admin/lead only. Non-leads must also be project members before a signed storage URL is minted.

Webhook Rules​

fathom-webhook disables Supabase JWT verification because Fathom cannot provide a Supabase session. It instead verifies Fathom HMAC headers:

  • webhook-id
  • webhook-timestamp
  • webhook-signature

Each webhook id is claimed in audit before any work, so a replayed id is acknowledged and ignored.