Security model

Genie is secure by default: authorization is enforced by the server on every operation, and the client is never trusted. This page is the map; each layer has its own page.

The layers

1. Authentication — short-lived RS256 JWT + refresh tokens, cookie auth, MFA/TOTP and sessions. See Identity.
2. RBAC — per-resource permission verbs (List, View, Create, Update, Delete, Export, Import, Execute), re-validated on every request. See RBAC & permissions.
3. The disclosure gate — metadata (structure) is ungated beyond auth; record values and mutations require the matching verb. See The disclosure gate.
4. Parameter sanitisation — an allowlist strips caller-supplied parameters that the view didn’t declare, guarding mass-assignment and cross-tenant injection. See Parameter sanitisation.
5. Field & column security — per-field/column role and expression rules, enforced server-side on submit. See Field & column security.
6. Multi-tenancy — company scoping is enforced in SQL, not just filtered in the UI. See Multi-tenant company scoping.

The trust rule

The client is a hint, never an authority

Any permissions, canSubmit, hidden or disabled flags in a response exist so the UI can render sensibly. The server re-checks the real permission on every read and every write. A crafted request that flips a flag gets nothing it isn’t independently entitled to.

Related hardening

• Password encryption — user passwords are AES-encrypted at the database layer, with per-dialect cipher keys. See Password encryption.
• Assistant SQL isolation — the AI assistant runs generated SQL through a restricted, row-level-security-scoped login so a prompt can never cross tenant boundaries. See Tenant isolation & SQL hardening.
• Transport & uploads — CSP/HSTS headers, authenticated export downloads (no guessable static paths), and configurable upload size caps.