Comparatif rapide
| Mode | Où réside le texte chiffré | Qui peut déchiffrer | Cas d'usage idéal |
|---|---|---|---|
Mode géré dans le Cloud cloud | Plan de données géré par XMemo avec contrôles d'accès, autorisation délimitée au niveau de l'application et journaux d'audit. Le RLS en base de données dépend du déploiement. | Le serveur XMemo peut traiter le contenu de la mémoire pour le rappel, la recherche, le classement et les exportations prises en charge. | Configuration rapide, rappel hébergé complet, aucune charge liée aux appareils ou aux clés de récupération. |
Mode Keyguard keyguard | Postgres géré par XMemo, mais les clés d'enveloppe sont liées au KMS / HSM de votre organisation. | Le serveur ne peut déchiffrer que si l'autorisation (grant) de votre KMS autorise les opérations d'unwrap. | Équipes d'entreprise nécessitant un rappel hébergé associé au contrôle des clés gérées par le client. |
Mode Vault vault | Le Postgres géré par XMemo stocke du texte chiffré opaque et des métadonnées d'enveloppe. | Seuls les appareils enregistrés ou votre kit de récupération peuvent déchiffrer. XMemo ne peut pas récupérer le texte en clair. | Garde zero-knowledge où la perte de tous les appareils et éléments de récupération entraîne une perte définitive. |
Ce que XMemo stocke
- Enregistrements de mémoire : texte en clair ou texte chiffré de la mémoire, métadonnées, propriété, horodatages et données de recherche vectorielle nécessaires au rappel.
- État de configuration du compte : mode de sécurité sélectionné, état d'achèvement de la configuration, nombre de changements de mode et preuves de contrôle préalable (preflight) telles qu'un identifiant de liaison KMS ou un marqueur de récupération Vault.
- Enregistrements d'accès et d'audit : sessions, identifiants hachés ou délimités, liaisons d'identité et événements d'audit tels que setup_state_transition.
Les pages publiques de XMemo ne vous demandent jamais de coller des clés d'API. La configuration des agents et de MCP doit référencer des variables d'environnement ou la surface de configuration officielle du client.
Mode géré dans le Cloud
Les données de mémoire sont stockées dans le plan de données géré par XMemo avec des contrôles d'accès, une autorisation délimitée au niveau de l'application et des journaux d'audit. Le RLS en base de données dépend du déploiement.
- Le serveur XMemo peut traiter le contenu de la mémoire pour le rappel sémantique côté serveur, le classement et les exportations.
- Il s'agit du mode le plus pratique, mais il n'est pas zero-knowledge.
- La suppression retire les lignes de mémoire et les métadonnées associées. Les exportations DSAR peuvent inclure du texte en clair, car le service peut traiter le contenu de la mémoire en votre nom.
Mode Keyguard
Keyguard préserve l'expérience de rappel hébergé de XMemo tout en liant les opérations d'enveloppe à une clé contrôlée par votre organisation dans Azure Key Vault, AWS KMS, GCP KMS, KMIP ou un fournisseur similaire.
- L'assistant stocke la liaison KMS dans les données préalables de configuration et valide personal_default_mode = keyguard.
- Le rappel exige que votre autorisation (grant) KMS demeure valide. La révocation de cette autorisation bloque les futures opérations de déchiffrement et d'unwrap.
- XMemo supprime son texte chiffré et ses métadonnées lors de la suppression du compte ; votre organisation demeure responsable de la rotation ou de la destruction des clés KMS.
Mode Vault
Vault constitue l'option zero-knowledge. Le navigateur ou l'appareil chiffre les données avant qu'elles ne quittent l'appareil, et le serveur ne stocke que le texte chiffré ainsi que les métadonnées de routage et d'enveloppe.
- XMemo ne peut pas déchiffrer les mémoires Vault, ne peut pas réinitialiser votre clé Vault et ne peut pas récupérer les données si tous les appareils enregistrés et kits de récupération sont perdus.
- Les exportations DSAR pour les données Vault contiennent du texte chiffré et des métadonnées d'enveloppe. Vous les déchiffrez localement à l'aide de votre appareil ou de votre kit de récupération.
- Les fonctionnalités sémantiques hébergées peuvent être restreintes, à moins que la fonctionnalité ne puisse opérer sur des représentations fournies par le client ou préservant la confidentialité.
Frontière des données en production
L'environnement de production XMemo est conçu autour d'un Postgres géré par l'opérateur avec vérification TLS et autorisation délimitée au niveau de l'application. Le RLS en base de données et le contexte d'exécution dépendent du déploiement et nécessitent une vérification de la cible. Supabase est traité uniquement comme un backend de développement et de compatibilité, et non comme le substrat de production pris en charge pour ces garanties de garde.
- Postgres géré : la frontière de stockage en production pour les enregistrements de compte, de mémoire, de vecteurs, de configuration et d'audit.
- RLS en base de données et contexte d'exécution : contrôles spécifiques au déploiement exigeant la vérification sur l'environnement cible du rôle d'exécution, du registre de migrations, de l'indicateur runtime-context et de la matrice CRUD propriétaire/équipe.
- Compatibilité Supabase : utile pour l'adoption locale ou open source (OSS), mais le comportement de son rôle de service (service-role) n'équivaut pas au durcissement attendu en production.
Comment vérifier votre mode actif
- Ouvrez Memory Console -> Settings -> Security mode et confirmez le mode affiché.
- Appelez GET /api/v1/me/setup/state ; les comptes finalisés doivent afficher setup_state = setup_completed ainsi que le selected_mode attendu.
- Appelez GET /api/v1/me/security-mode ; l'état de posture doit inclure verified_effective_mode, new_write_mode, pending_write_mode, legacy_read_mode et migration_status.
- Pour Keyguard, comparez l'identifiant de liaison de clé affiché avec le journal d'audit de votre KMS. Pour Vault, confirmez que les écritures sortantes contiennent du texte chiffré opaque sans sous-chaîne reconnaissable en texte clair.
Source : Where is my data?