Política de seguridad

1. De qué partimos

El sistema está construido sobre dos supuestos incómodos: que el modelo de lenguaje puede equivocarse o ser manipulado, y que alguien puede intentar aprovecharlo. Todo lo que sigue es consecuencia de eso. Ninguna barrera confía en que la anterior haya funcionado.

2. Las credenciales de tus conexiones

• Se guardan con cifrado en sobre: cada conexión tiene su propia clave de datos y esa clave se guarda cifrada con una clave maestra que custodia un servicio de gestión de claves, nunca la base de datos ni el código.
• El usuario y la contraseña se cifran con AES-256-GCM, con un vector de inicialización distinto para cada uno. El identificador de tu cuenta va como dato autenticado: un registro copiado a otra cuenta no descifra.
• Se descifran en memoria y solo en el instante de abrir la conexión. No se escriben en registros, no se incluyen en mensajes de error y no se devuelven por la API — tampoco enmascaradas.
• El host, el puerto y el nombre de la base se guardan sin cifrar: hacen falta para conectar y no son el secreto.
• En la interfaz, la contraseña vive solo en el formulario y durante el envío. No se guarda en el navegador ni se manda a ninguna herramienta de analítica.

3. Por qué no puede escribir en tu base

Son tres barreras independientes:

• La credencial. Te pedimos un usuario de solo lectura, y la interfaz lo advierte al crear la conexión.
• La sesión. Toda conexión con tu base se abre dentro de una transacción de solo lectura, aunque el usuario que nos diste tuviera permisos de escritura.
• El validador. Cada consulta que escribe el agente se analiza sintácticamente antes de ejecutarse. Se rechaza cualquier cosa que no sea un único SELECT: sentencias de escritura o de definición, varias sentencias separadas por punto y coma, sentencias escondidas tras comentarios, SELECT ... INTO, subconsultas con escritura dentro y funciones que leen ficheros o abren conexiones de red. Es análisis del árbol sintáctico, no una lista de palabras prohibidas.

El mismo validador protege los tres motores que soportamos —PostgreSQL, MySQL y el que consulta tus archivos—, así que cerrar un caso lo cierra para todas las fuentes a la vez. Tiene pruebas automáticas con casos adversariales explícitos.

4. Cuidar tu base de producción

• Cada consulta lleva un límite de filas; si el modelo no lo puso, se lo añade el validador.
• Cada consulta tiene un tiempo máximo de ejecución, para que una pregunta ambiciosa no bloquee tu base.
• Las conexiones a tus fuentes usan un pool independiente del de nuestra propia base, con tope de conexiones simultáneas por cuenta y cierre por inactividad.

5. Qué sale de tu base y qué no

No copiamos tus tablas. Lo que guardamos de una conexión es su esquema: nombres de tablas, columnas y tipos. Al responder una pregunta, el resultado de la consulta se envía al modelo para que redacte la respuesta y se muestra en pantalla, pero no se persiste como tabla en nuestra base de datos.

Un archivo que subes sí se guarda, porque es la única copia con la que se puede responder. Se almacena bajo una clave propia de tu cuenta y su nombre original nunca llega al sistema de ficheros.

6. Autenticación y sesiones

• La sesión viaja en una cookie httpOnly. El navegador no puede leerla desde JavaScript, así que un fallo de tipo XSS no encuentra ningún token que robar: no hay nada de sesión en el almacenamiento local.
• La cookie de renovación está acotada a la ruta de autenticación de la API, así que no se envía en ninguna otra petición.
• Las contraseñas se guardan como hash con bcrypt y se exige un mínimo de 12 caracteres.
• Los enlaces de verificación de correo y de invitación son de un solo uso, aleatorios y guardados solo como hash: ni siquiera nosotros podemos reconstruirlos desde la base de datos.
• Las rutas privadas se comprueban también en el servidor, no solo en el navegador. Si la API no responde, se trata como sesión no válida.

7. Aislamiento entre cuentas

La cuenta activa se comprueba contra las membresías en cada petición, y qué fuentes ve cada persona se resuelve en un único sitio del servidor en vez de repetirse en cada pantalla. Retirar a alguien de una cuenta le corta el acceso en la petición siguiente. Las conexiones, los archivos y los resultados nunca se comparten entre cuentas, aunque los datos de conexión sean idénticos.

8. Auditoría

Cada consulta contra una fuente queda registrada con la persona, la fuente, la pregunta original, la consulta generada, las filas devueltas y la duración. También quedan los intentos que se bloquearon: saber qué no se ejecutó es tan útil como saber qué sí. Puedes consultarlo desde la aplicación.

9. Proveedores

Los terceros que intervienen y qué recibe cada uno están en la política de privacidad. Los pagos los procesa Stripe y los datos de tu tarjeta no pasan por nuestros servidores; los avisos de pago se verifican comprobando su firma criptográfica antes de aplicar nada.

10. Cómo desarrollamos

• Todo lo que entra por la API se valida contra un esquema declarado; no se confía en la forma de lo que llega.
• Los errores que devolvemos están saneados: nunca incluyen trazas, rutas internas, hosts ni credenciales.
• Nada de lo que devuelve el modelo se inserta como HTML en la página. Ni el texto, ni los valores de las tablas, ni la consulta coloreada.
• El cifrado de credenciales y el validador de consultas tienen pruebas unitarias con casos adversariales; son las dos piezas donde un fallo silencioso costaría más caro.

11. Cómo reportar una vulnerabilidad

Escribe a [CORREO DE SEGURIDAD] con los pasos para reproducirla. Nos comprometemos a acusar recibo, a mantenerte al tanto y a no emprender acciones legales contra quien investigue de buena fe, siempre que no acceda a datos de terceros, no degrade el servicio y nos dé un plazo razonable antes de publicarlo.

12. Lo que no afirmamos

Una página de seguridad que solo enumera virtudes no sirve para decidir nada. Así que también decimos lo que no tenemos:

• No tenemos certificaciones tipo SOC 2 o ISO 27001. Cuando las tengamos, lo dirá esta página con su fecha.
• No comprometemos un nivel de disponibilidad concreto salvo acuerdo escrito.
• Las respuestas del agente pueden ser incorrectas. Por eso cada una trae su consulta a la vista: para que puedas comprobarla antes de decidir con ella (ver los términos y condiciones).