Segurança

Um banco de dados por cliente

Sua memória não é uma linha em uma tabela compartilhada com uma coluna de cliente nela. banco de dados próprio. Não existem tabelas compartilhadas, nem consultas que envolvam vários clientes e possam dar errado, pois o limite é o próprio banco de dados, e não um filtro que alguém precise se lembrar de definir.

Esse limite é testado de fora em cada lançamento: duas contas reais, e todas as portas que retornam dados são verificadas para garantir que nenhuma delas consiga visualizar a outra. Um lançamento não é enviado a menos que isso seja confirmado.

Chaves, e quem pode usá-las

Não podemos mostrar a você sua própria chave.

As chaves API são exibidas para você apenas uma vez, no momento da criação. O que armazenamos é um hash SHA-256 — portanto, uma cópia do nosso banco de dados não permite que ninguém obtenha uma chave funcional, e nem nós nem um invasor conseguimos recuperar a sua chave. A revogação de uma chave entra em vigor no serviço em aproximadamente um minuto, e imediatamente na máquina que armazena suas informações.

As chaves podem ser reduzidas.

Uma chave não precisa ser onipotente. As chaves podem ser limitado por projeto — ler e escrever, somente leitura ou completamente invisível — que é a forma adequada para um contratado, um trabalho de CI ou um agente de finalidade única que não precisa ler o resto do seu trabalho. Uma chave com escopos corrompidos ou ilegíveis tem tudo negado em vez de ter tudo concedido.

Autenticação de dois fatores

Sua conta pode exigir um segundo fator na hora do login, e, quando ele é ativado, essa exigência é aplicada durante o processo de autenticação, e não apenas exibida como uma configuração. Recomendamos isso, mas não o impomos: sua memória só é tão protegida quanto a conta que a armazena. No entanto, tornar a eliminação de seus próprios dados condicionada à inscrição de um telefone seria pior.

Proteção contra seus próprios agentes

Esta é a parte que a maioria dos serviços não leva em consideração. Sua memória é constantemente manipulada por agentes de IA – e um agente pode cometer erros, receber instruções maliciosas escondidas dentro do conteúdo que lhe foi solicitado para ser lido, ou excluir algo errado horas antes de um humano perceber.

Portanto, o arquivo bruto das conversas é deliberadamente fora do alcance deles. Nenhum agente pode excluir uma única mensagem. Nenhum agente pode acessar os últimos três meses de forma alguma.O histórico mais antigo só pode ser removido em massa, por projeto. Excluir um projeto inteiro — a única ação que afeta todo o arquivo — não está disponível para os agentes de nenhum nível; isso é feito no painel da conta, onde uma pessoa digita o nome do projeto.

A razão pela qual isso é importante é simples: a memória curada é derivada, e o arquivo é o original. Tudo o que uma edição ruim perde pode ser reconstruído a partir da história. Nada pode reconstruir a história.

Criptografia, backups e onde seus dados estão armazenados

O tráfego é criptografado em trânsito com TLS. Em repouso, sua memória também é criptografada. duas vezes: Criptografia de volume completo por baixo, e, em cima disso, seu banco de dados — toda conversa, todo registro e o log de escrita antecipada — também é criptografado. sua própria chave por cliente, Separado de todos os outros clientes. A chave que desbloqueia o volume de armazenamento não é armazenada no servidor do banco de dados: um disco roubado, uma imagem vazada ou um disco desativado não representam problema algum.

A exclusão é criptográfica

Como cada cliente possui sua própria chave, apagar você não é uma solução viável para limpar o armazenamento. Sua chave foi destruída e seu banco de dados foi eliminado., E o que resta fica ilegível para qualquer pessoa, incluindo nós. Os backups criptografados são apagados imediatamente, em vez de serem deixados para expirar, e quaisquer cópias remanescentes são eliminadas à medida que nossos sistemas de backup são atualizados, no máximo em 30 dias. Não há nenhuma cópia que possamos recuperar.

O que a criptografia por cliente não cobre

Dois limites claros. O mecanismo de banco de dados mantém estatísticas internas de planejamento de consultas que coletam amostras dos valores das colunas; essas amostras ficam protegidas pela criptografia de volume, e não pela sua chave pessoal. A criptografia em repouso é exatamente isso — em repouso: o serviço precisa descriptografar seus dados para atender às suas buscas e realizar a curadoria, portanto “nós nunca acessamos seus dados” é nossa política e nossos controles de acesso, e não uma impossibilidade matemática. Preferimos indicar onde fica o limite a permitir que você pense que não existe um.

Os backups são feitos todas as noites. criptografados antes de saírem de nossas máquinas, E são armazenados fora do local, na UE, de acordo com um cronograma rotativo, sendo mantidos por até três meses. Quando uma conta é excluída, seus backups também são excluídos, e quaisquer cópias restantes são removidas dentro de 30 dias.

Sua memória é armazenada, indexada e pesquisada inteiramente dentro da UE — nossos servidores estão em Frankfurt e nossos backups em Falkenstein, ambos na Alemanha. Os resultados de busca são calculados em nossas próprias máquinas e nunca saem delas.

A única exceção é a curadoria por IA. O trecho que está sendo curado é enviado para Ollama, nos Estados Unidos, processado e devolvido. Os termos publicados pela Ollama estipulam que as entradas e saídas são processadas temporariamente e nunca são utilizadas para treinar modelos — esse é o compromisso deles, em suas próprias palavras, e o apresentamos como sendo deles, e não como uma promessa nossa. Nada mais deixa a UE. Se você precisar de uma solução que garanta que nada também saia da UE, isso está disponível em uma implantação dedicada — pergunte. Cada subprocessador, com seu propósito e localização, está listado no Política de Privacidade.

Como operamos

Menor privilégio, por padrão

O serviço é executado como um usuário sem privilégios dentro de seu contêiner, nunca como root. Sua função no banco de dados não é a de superusuário, e ele não pode ler arquivos do host. Isso é verificado automaticamente antes de cada lançamento, em vez de ser assumido.

Os endpoints internos são bloqueados na borda.

Os pontos finais que criam contas e validam chaves são acessíveis apenas pelo nosso próprio plano de controle, autenticados na borda da rede antes mesmo que uma solicitação chegue, e novamente por meio de um segredo compartilhado. Duas travas, não uma.

Falha encerrada

Quando algo está faltando ou é ilegível, o serviço recusa a solicitação em vez de fazer suposições. Uma chave não verificável é rejeitada. Permissões corrompidas não concedem nenhum acesso. Um segredo de assinatura do webhook ausente rejeita todos os eventos, em vez de confiar no que chega. Essa é uma postura deliberada: o modo de falha de um serviço de memória deve ser “sem resposta”, nunca “a resposta do cliente errado”.

Cada lançamento é verificado de fora.

Antes que qualquer versão seja lançada, um sistema automatizado analisa todo o produto, desde uma conta completamente nova, por meio de uma conexão de rede real: registro, emissão e revogação de chaves, armazenamento e recuperação de dados, isolamento entre duas contas ativas, exportação de dados e exclusão total. Ou o processo é concluído com sucesso, ou a versão não acontece.

Relatar um problema de segurança

Se você acredita ter encontrado uma vulnerabilidade, por favor, avise-nos antes de contar a qualquer outra pessoa. Nós trabalharemos com você. Os dados de contato estão disponíveis em /.well-known/security.txt ou escreva para [email protected]. Nós não ameaçamos pesquisadores que relatam de boa fé.

Requisitos mais complexos – um acordo de processamento de dados, uma implantação dedicada em uma região à sua escolha, ou a manutenção da curadoria dentro da UE – são coisas que lidamos diretamente. Pergunte.