Proxy d'entrée : l'identité du locataire est résolue dès la toute première entrée dans le système ; la clé de chiffrement par document du locataire en est sélectionnée. Seules les requêtes vérifiées avec une attribution valide du locataire peuvent accéder aux données de ce locataire — appliqué tout au long du cycle de vie de la requête.

Base de données (isolation des locataires au niveau des lignes, appliquée par l'application) : chaque enregistrement porte un ID de locataire et chaque requête est limitée au locataire authentifié. Cela est appliqué dans l'application et vérifié en continu par des tests inter-locataires automatisés dans notre pipeline CI et lors des revues de code. La Row-Level Security native de la base de données (Postgres RLS) est prévue comme couche de contrôle supplémentaire. Toutes les requêtes utilisent exclusivement des méthodes paramétrées et typées — ce qui empêche toute injection SQL par conception.

Stockage : Les données clients dans S3 sont chiffrées avec des clés KMS spécifiques à chaque locataire (CMK). Chaque locataire dispose de sa propre clé de chiffrement, définie dès l'attribution au proxy d'entrée.

Autorisation : Des contrôles d'accès basés sur les objets appliquent des règles (ACL) au niveau des documents, cas et autres entités — incluant la délégation et les durées d'expiration.

API : L'ID du locataire est extraite des claims JWT authentifiés. Chaque point d'accès applique un contrôle d'accès basé sur les rôles.