Security is enforced across identity, company scope, and data access.
Review the verified Workspace security model covering identity, server authorization, company-scoped records, database policies, private routes, and operational limits.
Identity and application authorization are different checks
Clerk supplies the signed-in identity context for protected application routes. Workspace then resolves that identity to a company user and evaluates company membership, access status, enabled modules, role permissions, and any per-user override.
Authentication confirms who is making a request. Authorization determines whether that person can perform the requested company action.
Company scope continues into the database
Business tables use company relationships so records can be filtered to the current tenant. The repository includes tenant-scoped Postgres Row Level Security migrations for exposed business data as a defense-in-depth layer.
RLS complements server checks; it does not make application permission checks optional. Supabase also recommends RLS on tables exposed through its Data API.
- Company membership is resolved before sensitive business operations.
- Server actions and APIs check the permission needed for the operation.
- Database policies restrict rows using company-aware predicates.
- Private panels and APIs remain excluded from public search and AI discovery.
Integration credentials stay on server paths
Google token retrieval and updates are implemented in server-only modules and database functions. Browser code should not receive service-role credentials, refresh tokens, or other server secrets.
Session controls, token rotation, dependency updates, logs, and database policy reviews remain ongoing operational responsibilities after deployment.