Security & Access Control

Role-based permissions per tenant: Admin (everything), User (data read/write + view schema objects), ReadOnly (view + data read). Permissions are granular and role-based — each one is shown in Access Management with a label and a description of what it unlocks; they are granted to roles, the UI hides what you can’t do, and the API enforces the same keys server-side. Two gates worth calling out: the table list and detail require tables.view, and reading a table’s metadata (columns/features) requires metadata.read. Raw SQL (the SQL Editor and the query / export_query tools) requires the Admin role; it does not prompt for an authenticator code. Raw SQL is read-only. Every statement runs as your own per-user database principal, which can read your data but can never change data or schema — an INSERT, UPDATE, DELETE or DDL statement is refused by the database with “Raw SQL is read-only; use the table tools to change data or schema.” Use the Schema Builder, the Data API or the table tools for changes. Credential tables (sign-in, key, token and connector-secret tables, and any view over them) are never readable through raw SQL, for any role. The tenant owner has full access to their own tenant.

Additional protections you may notice: step-up (2FA) tokens are tenant-bound — a step-up minted for one tenant won’t authorize actions in another; replacing your TOTP authenticator requires entering a current code (the new secret stays pending until you confirm it, so a half-finished swap can’t lock you out); Google sign-in is off unless your operator enables it; and malformed or tampered tokens are rejected with a clean 401 rather than a vague error.