Seguridad

Una base de datos por cliente

Su memoria no es una fila en una tabla compartida con una columna de cliente. Cada cliente tiene la suya propia. base de datos propia. No hay tablas compartidas ni consultas que involucren a varios clientes y que puedan causar errores, ya que el límite es la propia base de datos, y no un filtro que alguien tenga que acordarse de escribir.

Ese límite se prueba desde el exterior en cada lanzamiento: se utilizan dos cuentas reales, y se verifica cada puerta que devuelve datos para asegurarse de que ninguna pueda ver a la otra. Un lanzamiento no se envía a menos que eso se cumpla.

Claves, y quién puede usarlas

No podemos mostrarle su propia clave.

Las claves API se le muestran una sola vez, en el momento de su creación. Lo que almacenamos es un hash SHA-256; por lo tanto, una copia de nuestra base de datos no permite obtener una clave funcional, y ni nosotros ni un atacante podemos leer la suya. La revocación de una clave surte efecto en el servicio en aproximadamente un minuto, e inmediatamente en la máquina que sirve su memoria.

Las claves pueden reducirse.

Una llave no tiene por qué ser todopoderosa. Las llaves pueden ser Por proyecto — lectura y escritura, solo lectura o completamente invisible.

Autenticación de dos factores

Su cuenta puede requerir un segundo factor de autenticación al iniciar sesión, y cuando se activa, este se aplica en el momento del inicio de sesión, y no solo se muestra como una configuración. Lo recomendamos, pero no lo imponemos: su memoria está protegida solo en la medida en que lo esté la cuenta que la alberga; sin embargo, hacer que la eliminación de sus propios datos dependa de la inscripción de un teléfono sería aún peor.

Protección contra tus propios agentes

Esta es la parte en la que la mayoría de los servicios no piensan. Su memoria es manipulada continuamente por agentes de IA; y un agente puede cometer un error, recibir instrucciones maliciosas ocultas dentro del contenido que se le pide leer, o eliminar algo incorrecto horas antes de que una persona se dé cuenta.

Por lo tanto, el archivo completo de las conversaciones está deliberadamente fuera de su alcance. Ningún agente puede eliminar un mensaje individual. Ningún agente puede acceder en absoluto a los últimos tres meses.La historia más antigua solo puede eliminarse en bloque, por proyecto. Eliminar todo un proyecto —la única acción que afecta al archivo en su totalidad— no está disponible para los agentes de ningún nivel; esto se hace en el panel de la cuenta, donde una persona escribe el nombre del proyecto.

La razón por la que esto es importante es sencilla: la memoria curada es derivada, mientras que el archivo es el original. Todo lo que se pierde debido a una mala edición puede reconstruirse a partir de la historia. Nada puede reconstruir la historia.

Cifrado, copias de seguridad y dónde viven sus datos

El tráfico se cifra en tránsito con TLS. En reposo, su memoria también está cifrada. dos veces: Cifrado de volumen completo debajo, y encima tu base de datos — cada conversación, cada registro y el registro de escritura anticipada — está cifrado bajo tu propia clave por cliente, Separado del de cualquier otro cliente. La clave que abre el volumen de almacenamiento no se almacena en absoluto en el servidor de la base de datos: un disco robado, una imagen filtrada o una unidad desactivada no sirven para nada.

La eliminación es criptográfica.

Dado que cada cliente tiene su propia clave, borrarlo no es una búsqueda esperanzadora en el almacenamiento: Su clave ha sido destruida y su base de datos eliminada., Y lo que queda es ilegible para cualquiera, incluyéndonos a nosotros. Las copias de seguridad encriptadas se eliminan por completo en lugar de dejar que caduquen, y las copias restantes se borran a medida que nuestros sistemas de respaldo se actualizan, en un plazo máximo de 30 días. No hay ninguna copia que podamos recuperar.

Lo que la encriptación por cliente no cubre

Dos límites claros. El motor de la base de datos mantiene estadísticas internas de planificación de consultas que toman muestras de los valores de las columnas; esas muestras están protegidas por cifrado de volumen, no por tu clave personal. Y el cifrado en reposo es precisamente eso: en reposo. El servicio debe descifrar tus datos para responder a tus búsquedas y realizar tareas de curaduría, por lo que “nunca vemos tus datos” es nuestra política y nuestros controles de acceso, no una imposibilidad matemática. Preferimos indicarte dónde está el límite antes que permitir que supongas que no existe.

Las copias de seguridad se realizan cada noche y son Se cifran antes de salir de nuestras máquinas., Y se almacenan fuera de la sede, en la UE, según un calendario rotativo, durante un máximo de tres meses. Cuando se elimina una cuenta, sus copias de seguridad también se eliminan, y las copias restantes desaparecen en un plazo de 30 días.

Su memoria se almacena, indexa y busca íntegramente dentro de la UE: nuestros servidores están en Fráncfort y nuestras copias de seguridad en Falkenstein, ambos en Alemania. Los resultados de las búsquedas se calculan en nuestras propias máquinas y nunca salen de ellas.

La única excepción es la curaduría por IA. El texto que se va a curar se envía a Ollama, en los Estados Unidos, Se procesan y se devuelven. Los términos publicados por Ollama indican que las entradas y salidas se procesan de forma temporal y nunca se utilizan para entrenar modelos; ese es su compromiso, según sus propias palabras, y lo presentamos como tal, no como una promesa nuestra. Nada más sale de la UE. Si necesita que nada salga de la UE tampoco, eso está disponible en una implementación dedicada; pregunte. Cada subprocesador, con su finalidad y ubicación, está listado en el Política de privacidad.

Cómo operamos

Menor privilegio, por defecto

El servicio funciona como un usuario sin privilegios dentro de su contenedor, nunca como root. Su rol en la base de datos no es el de superusuario y no puede leer archivos desde el host. Todo esto se verifica automáticamente antes de cada lanzamiento, en lugar de asumirlo por defecto.

Los puntos finales internos están bloqueados en el borde.

Los puntos finales que proporcionan cuentas y validan claves solo son accesibles desde nuestro propio plano de control; se autentican en el borde de la red antes de que llegue cualquier solicitud, y nuevamente mediante un secreto compartido. Dos cerraduras, no una.

Falla cerrada

Cuando algo falta o no es legible, el servicio rechaza la solicitud en lugar de hacer conjeturas. Se rechaza una clave que no pueda verificarse. Los permisos dañados no otorgan ningún derecho. Un secreto de firma de webhook faltante rechaza todos los eventos en lugar de confiar en lo que llega. Esta es una postura deliberada: el modo de fallo de un servicio de memoria debería ser “ninguna respuesta”, nunca “la respuesta del cliente equivocado”.

Cada versión se verifica desde el exterior.

Antes de que se publique cualquier versión, un sistema automatizado recorre todo el producto desde una cuenta completamente nueva a través de una conexión de red real: registro, emisión y revocación de claves, almacenamiento y recuperación de memoria, aislamiento entre dos cuentas activas, exportación de datos y borrado total. O pasa la verificación por completo o la versión no se publica.

Informar sobre un problema de seguridad

Si cree que ha encontrado una vulnerabilidad, por favor háznoslo saber antes de decírselo a nadie más; trabajaremos con usted. Los datos de contacto se encuentran en /.well-known/security.txt o escribe a [email protected]. No amenazamos a los investigadores que informan de buena fe.

Requisitos más avanzados — un acuerdo de procesamiento de datos, un despliegue dedicado en la región que elija, o mantener la curaduría dentro de la UE — son cosas que gestionamos directamente. Pregunte.