XMemo Security Modes

Where is my data?

This page explains what XMemo stores for each security mode, where it is processed, who can decrypt it, what happens during export or deletion, and how you can verify the active boundary from your own account.

Quick comparison

Mode	Where ciphertext lives	Who can decrypt	Best fit
Cloud-managed mode `cloud`	XMemo managed Postgres, encrypted at rest with per-user Cloud KEK references.	XMemo server can decrypt on your behalf for recall, search, ranking, and supportable exports.	Fast setup, full hosted recall, no device or recovery-key burden.
Keyguard mode `keyguard`	XMemo managed Postgres, but envelope keys are bound to your tenant KMS / HSM.	The server can decrypt only when your KMS grant allows unwrap operations.	Enterprise teams that need hosted recall plus customer-managed key control.
Vault mode `vault`	XMemo managed Postgres stores opaque ciphertext and envelope metadata.	Only enrolled devices or your recovery kit can decrypt. XMemo cannot recover plaintext.	Zero-knowledge custody where losing all devices and recovery material means permanent loss.

What XMemo stores

Memory records: memory text or ciphertext, metadata, ownership, timestamps, and vector-search data needed for recall.
Account setup state: selected security mode, setup completion state, mode-change count, and preflight proof such as a KMS binding id or vault recovery marker.
Access and audit records: sessions, hashed or scoped credentials, identity links, and audit events such as setup_state_transition.

XMemo public pages never ask you to paste API keys. Agent and MCP configuration should reference environment variables or the official client configuration surface.

Cloud-managed mode

Storage

Memory data is encrypted at rest in the XMemo managed data plane. The account is bound to a Cloud KEK reference such as cloud_kek_ref.

Decryption

The XMemo server can decrypt for server-side semantic recall, ranking, and exports. This is the most convenient mode, but it is not zero-knowledge.

Deletion and DSAR

Deletion removes memory rows and associated envelope metadata. DSAR exports can include plaintext because the service can decrypt on your behalf.

Keyguard mode

Keyguard keeps XMemo's hosted recall experience while binding envelope operations to a key your organization controls in Azure Key Vault, AWS KMS, GCP KMS, KMIP, or a similar provider.

The wizard stores the KMS binding in setup preflight data and commits personal_default_mode = keyguard.
Recall requires your KMS grant to remain valid. Revoking the grant blocks future decrypt/unwrap operations.
XMemo deletes its ciphertext and metadata on account deletion; your tenant remains responsible for KMS key rotation or destruction.

Vault mode

Vault is the zero-knowledge option. The browser/device encrypts before data leaves the device, and the server stores only ciphertext plus routing and envelope metadata.

XMemo cannot decrypt vault memories, cannot reset your vault key, and cannot recover data if every enrolled device and recovery kit is lost.
DSAR exports for vault data contain ciphertext and envelope metadata. You decrypt them locally with your device or recovery kit.
Hosted semantic features may be limited unless the feature can operate on client-provided or privacy-preserving representations.

Production data boundary

XMemo production is designed around operator-managed Postgres with TLS verification and runtime row-scoping controls. Supabase is treated as a development and compatibility backend only, not as the supported production substrate for these custody claims.

Managed Postgres: the production storage boundary for account, memory, vector, setup, and audit records.
RLS/runtime context: row access is scoped to the active user, tenant, and agent boundary.
Supabase compatibility: useful for local or OSS adoption, but its service-role behavior is not equivalent to production hardening.

How to verify your active mode

Open Memory Console -> Settings -> Security mode and confirm the mode shown there.
Call GET /api/v1/me/setup/state; completed accounts should show setup_state = setup_completed and the expected selected_mode.
Call GET /api/v1/me/security-mode; the posture should include verified_effective_mode, new_write_mode, pending_write_mode, legacy_read_mode, and migration_status.
For Keyguard, compare the displayed key binding id with your KMS audit log. For Vault, confirm outbound writes contain opaque ciphertext with no recognizable plaintext substring.