Cómo protege Rationale lo que decide tu equipo

Dos tipos de datos, separados

Rationale separa lo que necesita para operar el servicio de lo que escribe tu equipo. El primer tipo (identificadores, estados, anclas, marcas de tiempo, nombres de repositorios, ramas y archivos, handles de tareas) lo puede leer el servidor, porque el enrutado, los avisos y la auditoría lo necesitan. El segundo tipo se cifra en la base de datos con claves guardadas en el entorno del despliegue, nunca en la base de datos ni en el repositorio: el texto de las decisiones (pregunta, elección, criterios, opciones descartadas, supuestos, condiciones de revisión y citas), notas, tareas, traspasos, resúmenes, digests y títulos de sesión; títulos, descripciones e hilos de revisión de pull requests; tokens de conectores; y los nombres, nombres de usuario, direcciones de correo y fotos que Jira y GitHub dan de las personas.

El contenido del segundo tipo nunca pasa a columnas, logs, eventos ni mensajes de error del primero. Los logs de peticiones filtran el texto de las decisiones y las credenciales, y los eventos de auditoría llevan solo ids, números y estados. El contenido de las decisiones es de solo anexar: una edición añade una versión y no sobrescribe nada.

Qué se queda en tus máquinas

• Transcripciones. El cliente extrae las decisiones en la máquina de la persona con el agente que ya usa. Nosotros recibimos las decisiones, citas breves de las propias palabras de la persona y metadatos (id de sesión, números de turno, repositorio, rama, commit, hora, coste equivalente). La transcripción en sí no va a ningún sitio salvo al proveedor del propio agente, como siempre ha ocurrido.
• Repositorios. Nunca los clonamos y no guardamos archivos. Una decisión se ancla a rutas; cuando una decisión nombra una clase, una tabla o la clave de un ticket, la comparación con el contenido de un archivo ocurre en la máquina, sobre 512 KB de texto como máximo, y ese contenido nunca sale de ella.
• Rutas de archivos. Cuando tu agente lee o edita un archivo, el hook compara su ruta con un índice local de decisiones ancladas y consulta al servidor solo si hay coincidencia. Una ruta a la que no está anclada ninguna decisión nunca sale de la máquina.
• Secretos. El valor de un secreto nunca entra en una decisión, una nota ni un traspaso: se rechaza en lo que escriben personas y agentes, y se tacha del texto capturado y de las citas. El escaneo busca claves privadas, claves de nube y de API, tokens de GitHub, GitLab, Slack y Stripe, JWT, contraseñas dentro de URL y valores escritos tras palabras como password o token; el servidor registra solo el tipo de secreto que rechazó, nunca el valor. Los hosts, las URL y dónde vive un secreto (una ruta en un vault, el nombre de una variable de entorno) son bienvenidos.

En tránsito

• Toda conexión con Rationale usa HTTPS, con certificados de Let's Encrypt y HTTP Strict Transport Security incluyendo subdominios; el HTTP plano se redirige.
• El cliente verifica TLS con el almacén de certificados de tu plataforma, así que un proxy corporativo con su propio certificado raíz funciona sin debilitar nada.
• Las entregas de webhooks de GitHub y Jira se aceptan solo con una firma válida del proveedor.
• Los correos que enviamos salen por una conexión cifrada hacia nuestro proveedor de correo.
• Este sitio web no pone cookies, no carga scripts de terceros y envía una Content-Security-Policy que permite solo sus propios scripts, con hash. La aplicación pone solo la cookie firmada que te mantiene con la sesión iniciada; ninguno de los dos lleva rastreadores.

Inicio de sesión

• Sin contraseñas. Rationale no guarda ninguna. Las personas inician sesión con un enlace enviado a su correo que funciona una sola vez, durante 15 minutos; el token viaja después del # de la dirección, que los navegadores nunca envían a un servidor, así que nunca llega a nuestros logs ni al proxy de nadie. Una sesión de navegador dura 30 días.
• Dispositivos. rationale init inicia la sesión de una máquina con un código de dispositivo: el cliente muestra un código de ocho letras, lo introduces en la aplicación con la sesión iniciada, eliges el espacio de trabajo y permites o deniegas. Los códigos caducan a los 10 minutos y se guardan como digests. El token del dispositivo se entrega una vez, se guarda como digest SHA-256, está limitado a un espacio de trabajo, deja de funcionar tras 90 días sin uso y se puede revocar en cualquier momento desde la página Devices; quitar a un miembro revoca los suyos.
• Clientes MCP. Claude, ChatGPT, Cursor y cualquier cliente MCP se conectan con OAuth 2.1: registro dinámico de clientes, solo clientes públicos, PKCE con S256 obligatorio, direcciones de redirección por HTTPS o loopback. Los códigos de autorización duran 5 minutos y son de un solo uso, los tokens de acceso duran una hora, los tokens de refresco rotan en cada uso y duran 90 días. En la página de consentimiento eliges a qué espacios de trabajo puede llegar el cliente; tu membresía se vuelve a comprobar en cada petición, y la conexión se revoca desde la misma página Devices.
• Sin claves de API para personas. No hay ninguna clave personal que pegar en un archivo de configuración ni que filtrar en un repositorio. Las únicas credenciales son el token de un dispositivo y los tokens de una conexión MCP, cada uno revocable por separado.
• Conectores. Jira y GitHub se conectan por OAuth con la cuenta de cada miembro, nunca con un token compartido ni una contraseña. El viaje de ida y vuelta usa un estado aleatorio de un solo uso, que dura 10 minutos y está ligado a la sesión de navegador que lo inició.
• Límites de frecuencia. Los enlaces de inicio de sesión, los códigos de dispositivo, los endpoints de OAuth y MCP y el script de instalación tienen límites de frecuencia por dirección o por token.

Quién puede ver qué

• Espacios de trabajo. Cada registro pertenece a un espacio de trabajo y solo se accede a él a través de ese espacio: un espacio al que no perteneces es indistinguible de uno que no existe. Los propietarios gestionan la membresía, los conectores y el registro de auditoría.
• Tu propia vista de Jira y GitHub. Los conectores usan OAuth con la cuenta de cada miembro, nunca un token compartido, así que cada persona ve en Rationale solo los tickets, proyectos, repositorios y pull requests que su propia cuenta puede ver.
• Registros privados. Una decisión, un traspaso, una tarea creada en Rationale o una sesión entera pueden ser privados: visibles para su persona y sus propios agentes, nunca para el equipo, propietarios incluidos. Decide la persona, con un clic o con sus propias palabras a través de su agente; un agente nunca cambia la visibilidad por su cuenta.
• Los agentes actúan como ellos mismos. Un agente trabaja a través del dispositivo o la conexión MCP de un miembro, etiquetado como agente, en nombre de ese miembro. Nunca ve más que la persona para la que trabaja.

Qué puede y qué no puede ver nuestro personal

El personal de Rationale usa un panel de administración en su propio host, que se abre con un enlace por correo solo para personal en una sesión de 8 horas detrás de una cookie limitada a ese host; una sesión de miembro nunca lo abre. Muestra la maquinaria de cada cliente en números: capturas, fallos, dispositivos, trabajos, métricas.

• No puede descifrar. Cada petición al panel corre con un proveedor de claves que no tiene claves, así que leer cualquier atributo cifrado lanza un error en lugar de mostrarlo. Una prueba recorre todas las páginas del panel con contenido centinela y falla si ese contenido aparece, en claro o como texto cifrado.
• Cada mirada queda en tu registro. Cada página del panel que muestra datos de un espacio de trabajo escribe un evento staff.viewed en el registro de auditoría de ese espacio, donde los propietarios lo leen con el filtro Staff.
• Sin iniciar sesión como otra persona. El personal no tiene forma de abrir tu espacio de trabajo como tú. Ninguna página, API ni herramienta MCP puede conceder la marca de personal: solo cambia desde la consola de producción auditada.
• Las consolas quedan registradas. Una consola de producción puede leer contenido, así que abrir una escribe un evento ops.console_opened con el operador antes de aceptar entrada; si el evento no se puede escribir, la consola no se abre. Abrimos una solo para un soporte que pediste, una solicitud de privacidad o un incidente.
• Las herramientas de privacidad también se auditan. Exportar o borrar a una persona, exportar o eliminar un espacio de trabajo se hace con herramientas auditadas que escriben sus propios eventos, sin contenido; la exportación de un espacio se envía solo a uno de sus propietarios.

Cada lectura queda registrada

Cada creación, lectura y confirmación de una decisión escribe un evento de auditoría: una decisión abierta, una lista o una búsqueda mostrada, contexto entregado a un agente, un aviso mostrado. Los eventos llevan ids, números y estados, nunca contenido, y son de solo anexar. Los propietarios leen el registro de su espacio de trabajo en Ajustes, con la actividad de miembros, agentes y personal, el canal (web, cliente, MCP) y la dirección IP, filtrado por cambios, lecturas o accesos del personal.

La procedencia es explícita en cada registro: observado, derivado, inferido por un agente o confirmado por una persona. Un registro pasa a confirmado solo mediante una acción humana: un clic en la aplicación, las propias palabras de la persona en una sesión (el cliente las comprueba contra la transcripción antes de enviarlas y descarta cualquier cosa que un agente haya escrito sobre que una persona confirmó), o la fusión en GitHub del pull request que llevó la decisión en su rama. Que un agente diga que alguien confirmó no es una confirmación.

El cliente

• Un binario, sin runtime. Se instala en tu directorio personal sin sudo y nunca edita los archivos de tu shell. La primera instalación confía en TLS hacia el host de archivos, como todo curl | sh; cada actualización posterior la verifica el propio cliente contra un manifiesto firmado.
• Cada versión está firmada con minisign. Dos claves públicas van compiladas en cada binario: la clave de release, que firma cada manifiesto, y una clave de respaldo fuera de línea que solo sirve para rotar la primera; las claves secretas nunca van a un repositorio ni a un servidor. Una actualización que ninguna de las dos firmó, un manifiesto reproducido o una bajada de versión se rechazan; se comprueban el tamaño y el SHA-256 de cada archivo; un binario nuevo que falla su autocomprobación se revierte, y rationale update --rollback devuelve la versión anterior a petición.
• Su configuración solo la puede leer tu usuario (modo 600). Los hooks nunca bloquean a tu agente: cada uno hace como mucho una petición corta, de dos segundos como máximo, y el que falla termina en silencio.
• rationale uninstall quita los hooks y el watcher; revocar el dispositivo en la aplicación invalida su token.

Dónde corre el servicio

Un servidor y una base de datos PostgreSQL gestionada en DigitalOcean, accesible por la red privada, con copias de seguridad diarias y siete días de recuperación a un punto en el tiempo. El cortafuegos permite solo SSH, HTTP y HTTPS; SSH es solo con clave; las actualizaciones de seguridad se instalan sin intervención. Los secretos llegan al servidor como variables de entorno al desplegar, legibles solo por root, nunca en el repositorio ni en la base de datos. Cada cambio pasa las pruebas, Brakeman, bundler-audit e importmap audit en CI antes de fusionarse. Nuestras cuentas en los proveedores usan autenticación de dos factores.

Estamos establecidos en Portugal, así que las transferencias a Estados Unidos se hacen conforme al RGPD: la certificación de DigitalOcean bajo el Marco de Privacidad de Datos UE-EE. UU. (con sus extensiones para el Reino Unido y Suiza) y las Cláusulas Contractuales Tipo de su acuerdo de tratamiento de datos; las Cláusulas Contractuales Tipo y el Marco de Privacidad de Datos en el caso de Resend. Cada proveedor está bajo un acuerdo de tratamiento de datos por escrito. La política de privacidad mantiene la lista de referencia.

Cuánto tiempo guardamos los datos

El contenido del espacio de trabajo (decisiones, tareas, notas, traspasos) se conserva mientras exista el espacio y se elimina en los 30 días siguientes a la petición de un propietario o 90 días después de que termine el servicio; las copias de seguridad desaparecen en siete días. Los datos personales tienen plazos publicados, que un trabajo diario hace cumplir:

La política de privacidad es la lista de referencia. Los propietarios pueden pedir una exportación de todo el espacio de trabajo (descifrada, enviada solo a un propietario) o su eliminación; una persona puede pedir su propia exportación o borrado en privacy@rationalehq.com.

Si algo sale mal

Tenemos un plan de respuesta a incidentes por escrito, a cargo del gerente de la empresa. Cubre un secreto o token filtrado, un portátil o una cuenta de proveedor robados, un acceso no autorizado, datos enviados a la persona equivocada, datos perdidos o corruptos y una vulnerabilidad explotada. Ante la duda, tratamos un evento como incidente y lo escribimos en el registro.

1. Contener, en la primera hora: rotar lo que se filtró, revocar dispositivos y conexiones, apagar un conector, bloquear una dirección, poner un servidor fuera de línea si hace falta; copiar los logs antes de que roten.
2. Escribirlo en el registro de brechas, con horas en UTC, solo hechos, conservado al menos cinco años.
3. Evaluar qué datos, de quién y si estaban cifrados: el contenido de las decisiones se cifra con claves fuera de la base de datos, así que una copia de la base de datos sin las claves expone solo identificadores y estados.
4. Notificar: a los propietarios de cada espacio de trabajo afectado en 48 horas, por correo, con lo que pasó, qué datos, qué hicimos y qué deberían hacer; a la autoridad portuguesa de protección de datos en 72 horas cuando el RGPD lo exija, y a las personas afectadas sin dilación indebida cuando el riesgo para ellas sea alto; a Atlassian en 48 horas cuando esté implicado el conector de Jira; a los residentes en EE. UU. según exija la ley de su estado.
5. Recuperar desde las copias de seguridad (siete días de recuperación a un punto en el tiempo), volver a desplegar, verificar.
6. Aprender: causa raíz, corrección, actualizar el plan y el registro de actividades de tratamiento.

El registro no tiene entradas a la fecha de esta página. El plan prevé un simulacro al menos una vez al año, anotado en el registro.

Cumplimiento y certificaciones

Rationale es un servicio de una empresa portuguesa y opera bajo el RGPD para todo el mundo, esté donde esté. La política de privacidad nombra cada proveedor, cada finalidad y cada plazo de conservación. Los términos incluyen Condiciones de Tratamiento de Datos, con notificación de un incidente de seguridad que afecte a datos personales sin dilación indebida y en 48 horas, y Términos de Privacidad para los Estados de EE. UU. No vendemos datos personales, no mostramos publicidad, no usamos analítica de terceros y no entrenamos modelos de IA con tu contenido.

Certificaciones: ninguna todavía. No tenemos certificación SOC 2 ni ISO 27001, y no hay ninguna auditoría en marcha. SOC 2 está previsto cuando Rationale tenga la tracción que lo justifique; esta página dirá cuándo empieza una auditoría y cuándo hay un informe disponible. Hasta entonces, esta página, la política de privacidad y los términos son la evidencia, y respondemos cuestionarios de seguridad a petición en security@rationalehq.com.

Lo que falta todavía

Dicho claramente, para que no tengas que preguntar:

• SOC 2 e ISO 27001. Sin informe y sin auditoría en marcha. Previsto con tracción.
• SSO con SAML y aprovisionamiento SCIM. No construidos. Pertenecen al plan Business, que no se vende hasta que existan. Hoy cada miembro inicia sesión con un enlace por correo, y los propietarios añaden y quitan miembros a mano.
• Exportación del registro de auditoría. Los propietarios leen el registro en Ajustes; todavía no hay descarga. Previsto para el plan Business.
• Un segundo factor propio. El inicio de sesión es por enlace de correo, así que la protección de tu buzón es la de tu cuenta; Rationale no añade un segundo factor propio.
• Notarización de Apple del binario de macOS. Las versiones están firmadas con minisign y las verifica el propio cliente, pero Apple no las ha notarizado todavía, así que instala con el comando o con Homebrew en lugar de una descarga desde el navegador.
• Windows. El cliente funciona en macOS y Linux; en Windows el instalador lo dice y se detiene.
• Alojamiento fuera de Estados Unidos. Los datos viven en Estados Unidos bajo los mecanismos de transferencia de arriba; todavía no hay una región en la UE.

Reportar una vulnerabilidad

Escribe a security@rationalehq.com. Acusamos recibo en un día laborable, te mantenemos informado mientras lo corregimos y no tomamos medidas contra la investigación de buena fe que respete los datos de otros clientes. Nuestro security.txt dice lo mismo, en formato legible por máquinas.

• Incluye el host, los pasos para reproducirlo y lo que observaste.
• No accedas, cambies ni conserves datos que no sean tuyos; para en cuanto el problema quede demostrado.
• Danos un tiempo razonable para corregirlo antes de hacerlo público.