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 exigir un segundo factor al iniciar sesión y, cuando lo activa, se aplica en cada inicio de sesión — después de la contraseña y después de GitHub o Google por igual — y no se limita a mostrarse como una configuración.

Crear una clave de API requiere un inicio de sesión protegido: autenticación de dos factores en tu cuenta, o un inicio de sesión a través de GitHub o Google. Una contraseña por sí sola nunca crea una clave — ni siquiera en una cuenta que también tenga GitHub o Google conectados, porque lo que cuenta es cómo iniciaste sesión esta vez.

Cada acto destructivo — eliminar un proyecto, redactar el historial, eliminar la cuenta, restaurar una copia de seguridad — vuelve a preguntar quién eres: tu contraseña si tienes una, y tu código de dos factores; sin dos factores, un inicio de sesión de GitHub o Google de los últimos diez minutos. Exportar tus datos nunca lo necesita.

Inicia sesión con GitHub o Google

Iniciar sesión a través de GitHub o Google utiliza el flujo estándar de código de autorización con PKCE, vinculado al navegador que lo inició. Recibimos tu dirección de correo electrónico, tu nombre y el ID de tu cuenta en ese servicio — nada más. No conservamos ningún token de acceso de GitHub ni de Google, y no podemos leer tus repositorios, tu correo ni tus archivos. Una cuenta de GitHub o de Google se une a una cuenta de Brethof existente solo cuando ese servicio ha verificado la dirección de correo electrónico y nosotros también, o cuando la cuenta aún no tiene contraseña.

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 sin procesar de las conversaciones está deliberadamente fuera de su alcance. Ningún agente puede eliminar un solo mensaje. Ningún agente puede tocar en absoluto los últimos tres meses. El historial más antiguo solo puede eliminarse en bloque, por proyecto. Eliminar un proyecto entero —la única acción que afecta al archivo en su totalidad— no está disponible para los agentes de ningún nivel; se realiza 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

Tu memoria es un contenedor por cliente: su propia base de datos, su propio sistema de archivos, su propio usuario Linux; nada compartido. Si eliges la modalidad local, ese contenedor se ejecuta en tu máquina: tu memoria se almacena contigo y nosotros no almacenamos nada de ella. Lo que transita por nuestro hub —nuestra instancia de cómputo seguro en Zúrich, Suiza— es el contenido que se procesa: cada intercambio, y los fragmentos de memoria que tu contenedor envía cuando se necesita un juicio o se compone un resumen de sesión. La Sección 4 de la Política de Privacidad los enumera con exactitud. Nada de ello se retiene.

Qué es el software de tu máquina

El contenedor alberga tu memoria, la búsqueda sobre ella y la mecánica que mantiene ambas correctas. No contiene ningún prompt, ni acceso a ningún modelo de IA, ni ajuste alguno que lo dirija hacia uno. No hay nada en él que pueda juzgar tu memoria, ni nada que configurar que se lo permita. Cada juicio se solicita a nuestro hub a través de una conexión que tu contenedor abre de forma saliente y autentica; nosotros nunca nos conectamos entrando.

Esa estructura es lo que hace auditable el tráfico, y está pensado para que tú lo audites: los intercambios suben, los fragmentos anteriores suben, los comandos y las filas bajan. El cliente es source-available: lee cada una de sus líneas.

Hay algo que permanece íntegramente de tu lado: buscar en tu propia memoria —los registros, toda la historia y sus líneas de decisión fechadas— se ejecuta como una simple lectura de tus propias tablas, dentro de tu propio contenedor. Funciona sin necesidad de acceder a nuestro centro y no envía nada para ser evaluado.

En la versión alojada, el tráfico se cifra durante su transmisión mediante TLS; además, todo el sistema de archivos de su contenedor —cada conversación, cada registro, la propia base de datos— se cifra con una clave derivada de una frase de paso que solo usted posee. Nunca la vemos ni la almacenamos: esta clave transmite al iniciar su sesión, desbloquea su memoria, y la memoria se vuelve a bloquear automáticamente una vez que usted se aleja. Un contenedor bloqueado es texto cifrado para todos, incluyéndonos a nosotros; un disco robado, una imagen filtrada o una unidad desmantelada no representan ninguna amenaza, al igual que nuestro propio acceso root cuando usted no está presente.

La eliminación es criptográfica.

Borrarle no implica un barrido esperanzado del almacenamiento: su contenedor cifrado es destruido por completo. Y como para eliminar texto cifrado no se necesita ninguna clave, esto funciona incluso si ha olvidado su frase de paso. Las copias de seguridad que quedan son ilegibles sin ella y se borran a medida que avanza el ciclo de respaldo, en un plazo máximo de 30 días. No hay ninguna copia que podamos recuperar.

Lo que el cifrado no cubre

Límites honestos. El cifrado en reposo es precisamente eso: en reposo; mientras su memoria está desbloqueada para una sesión, el contenedor necesariamente trabaja con sus datos en texto plano para satisfacer sus búsquedas, por lo que “nunca revisamos sus datos” es nuestra política y nuestros controles de acceso, no una imposibilidad matemática; la garantía matemática se obtiene siempre que el contenedor está bloqueado. Preferimos indicarle dónde está el límite en lugar de dejar que suponga que no existe.

Las copias de seguridad de los contenedores alojados consisten en la extracción del sistema de archivos cifrado en sí, es decir, texto cifrado antes de que salga de la máquina, ilegible sin su frase de paso, conservado en una breve escala móvil de copias diarias y semanales en Alemania. Cuando se elimina una cuenta, sus copias de seguridad también se eliminan, y las copias restantes se borran dentro de 30 días.

La memoria alojada se almacena, indexa y busca íntegramente dentro de la UE; nuestros servidores y copias de seguridad se encuentran en Alemania. Los embeddings de búsqueda se calculan en nuestras propias máquinas y nunca salen de ellas. La memoria local nunca llega a todo esto: está en su disco, bajo la protección que usted le dé a dicho disco.

La única excepción es la curación por IA. Cada pasaje que se cura se procesa en nuestra instancia de cómputo seguro en Zúrich, Suiza —un país que la UE considera que ofrece un nivel adecuado de protección de datos— y desde allí se envía una sola pasada del modelo a Ollama, que aloja este modelo en Estados Unidos y Europa, lo procesa y lo devuelve. 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 propios términos, y lo citamos como suyo en lugar de como una promesa nuestra. Nada más sale de la UE. Si necesita que la curación tampoco salga nunca de la UE, eso está disponible mediante una implementación dedicada; pregunte. Cada subprocesador, con su finalidad y ubicación, se enumera en la 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 hello@Brethof.ai. 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.