Comparação rápida
| Modo | Onde o texto cifrado é armazenado | Quem pode descriptografar | Uso recomendado |
|---|---|---|---|
Modo gerenciado em Cloud cloud | Plano de dados gerenciado pelo XMemo, protegido por controles de acesso, autorização com escopo no nível da aplicação e trilhas de auditoria. A eficácia do RLS no banco de dados depende da verificação de cada implantação. | O servidor do XMemo pode processar o conteúdo da memória para recuperação (recall), busca, classificação e exportações suportadas. | Configuração mais rápida, capacidade total de recuperação hospedada, sem o encargo de gerenciar dispositivos ou chaves de recuperação. |
Modo Keyguard keyguard | Postgres gerenciado pelo XMemo, mas a chave de envelope (envelope key) é vinculada ao KMS / HSM da sua organização. | O servidor só pode descriptografar quando a concessão (grant) do seu KMS permitir a operação unwrap. | Equipes corporativas que exigem tanto recuperação hospedada quanto chaves sob controle do cliente. |
Modo Vault vault | O Postgres gerenciado pelo XMemo armazena apenas texto cifrado opaco e metadados de envelope (envelope metadata). | Apenas dispositivos registrados ou o kit de recuperação podem descriptografar; o XMemo não consegue recuperar o texto não criptografado. | Custódia de conhecimento zero (Zero-knowledge); a perda de todos os dispositivos e materiais de recuperação significa perda permanente. |
O que o XMemo armazena
- Registros de memória: texto simples ou texto cifrado da memória, metadados, propriedade, carimbos de data/hora e dados de busca vetorial necessários para a recuperação.
- Estado de configuração da conta: modo de segurança selecionado, status de conclusão da configuração, contagem de transições de modo e comprovações de pré-verificação (preflight), como o ID de vinculação de KMS ou o marcador de recuperação do Vault.
- Registros de acesso e auditoria: sessões, credenciais com escopo ou hashes, vínculos de identidade e eventos de auditoria como setup_state_transition.
As páginas públicas do XMemo nunca pedirão para colar uma chave de API. As configurações de agentes e MCP devem referenciar variáveis de ambiente ou usar as interfaces oficiais de configuração de cliente.
Modo gerenciado em Cloud
Os dados de memória são armazenados no plano de dados gerenciado pelo XMemo. O servidor processa o conteúdo da memória para recuperação, busca, classificação e exportação.
- O servidor do XMemo pode processar o conteúdo da memória para recuperação semântica no lado do servidor, classificação e exportação.
- É o modo mais conveniente, mas não é um modo de conhecimento zero (Zero-knowledge).
- A exclusão remove as linhas de memória e os metadados associados; exportações DSAR podem incluir texto não criptografado.
Modo Keyguard
O Keyguard mantém a experiência de recuperação hospedada do XMemo, ao mesmo tempo em que vincula as operações de envelope a chaves no Azure Key Vault, AWS KMS, GCP KMS, KMIP ou provedores similares controlados pela sua organização.
- O assistente salva a vinculação do KMS e confirma personal_default_mode = keyguard.
- A recuperação exige que a concessão (grant) do KMS permaneça ativa; revogar a concessão bloqueia qualquer operação posterior de descriptografia/unwrap.
- O XMemo exclui seu próprio texto cifrado e metadados; a rotação ou destruição da chave KMS permanece sob custódia da sua organização.
Modo Vault
O Vault é a opção de conhecimento zero (Zero-knowledge). O navegador ou dispositivo criptografa os dados antes que eles saiam do dispositivo, e o servidor retém apenas o texto cifrado, informações de roteamento e metadados de envelope.
- O XMemo não pode descriptografar memórias do Vault, não pode redefinir chaves do Vault e não pode recuperar dados se todos os dispositivos e kits de recuperação forem perdidos.
- Exportações DSAR de dados no Vault contêm texto cifrado e metadados de envelope, que devem ser descriptografados localmente usando um dispositivo ou kit de recuperação.
- Os recursos semânticos hospedados podem ser limitados, a menos que o recurso possa operar sobre representações fornecidas pelo cliente ou com preservação de privacidade.
Limite de dados em produção
A arquitetura de produção do XMemo é delimitada por Postgres gerenciado pelo operador, verificação TLS e autorização com escopo no nível da aplicação. A eficácia do RLS/contexto de runtime no banco de dados depende da verificação de cada implantação. O Supabase é fornecido apenas como backend de desenvolvimento e compatibilidade, não sendo um substrato de produção suportado para essas garantias de custódia.
- Postgres gerenciado: o limite de armazenamento em produção para contas, memórias, vetores, configurações e registros de auditoria.
- RLS no banco de dados / contexto de runtime: são controles específicos da implantação; o papel de runtime, o histórico de migrações, a flag de runtime-context e a matriz CRUD de proprietário/equipe devem ser validados no ambiente alvo.
- Compatibilidade com Supabase: adequado para ambientes locais ou adoção de código aberto (OSS), mas o comportamento de service-role não equivale ao endurecimento de segurança em produção.
Como verificar o modo atual
- Abra Memory Console -> Settings -> Security mode e confirme o modo exibido na tela.
- Chame GET /api/v1/me/setup/state; uma conta com configuração concluída deve retornar setup_state = setup_completed e o selected_mode esperado.
- Chame GET /api/v1/me/security-mode; a postura deve expor verified_effective_mode, new_write_mode, pending_write_mode, legacy_read_mode e migration_status.
- Keyguard: confira o key binding id exibido na tela com os logs de auditoria do seu KMS. Vault: confirme se as solicitações de gravação de saída contêm apenas texto cifrado opaco sem strings legíveis reconhecíveis.
Origem: Where is my data?