Seguridad

Dónde viven los datos

• Los documentos son archivos markdown en Amazon S3, región us-east-1, con versionado activado: cada escritura crea una versión nueva y las anteriores quedan.
• Las cuentas, workspaces, API keys y la cola de revisión viven en una base SQLite en el disco de un servidor EC2 propio, también en us-east-1.
• El índice de búsqueda es una caché descartable: se reconstruye desde los archivos y no es fuente de verdad de nada.
• Si conectás tu propio storage (S3 o un repo de GitHub tuyo), los documentos viven ahí y fluws solo los lee y escribe con las credenciales que vos configures.

Quién puede leerlos

• Los miembros del workspace, cada uno con su cuenta. Un workspace no ve la memoria de otro: el aislamiento se aplica en cada consulta, no en la interfaz.
• Las API keys de ese workspace, con el permiso que les hayas dado. Una key nunca puede salirse de su workspace.
• El equipo que opera fluws tiene acceso técnico a la infraestructura, porque hace falta para mantenerla en pie. No leemos la memoria de nadie salvo que nos lo pidan para resolver un problema puntual.

API keys

• Se guardan hasheadas (SHA-256). Ni nosotros podemos recuperar una key: se muestra una sola vez, al crearla.
• Tienen permisos: solo lectura, leer y escribir, o leer, escribir y borrar. Un agente que solo consulta la memoria no necesita más que la primera.
• Se pueden rotar —cambia el secreto y se conserva el nombre, el permiso y el historial de autoría— y revocar, que corta el acceso al instante.
• Cada key muestra cuándo se usó por última vez, para detectar una que ya nadie usa y no debería seguir viva.

En tránsito y en la aplicación

• Todo el tráfico va por HTTPS con HSTS; el puerto 80 solo redirige.
• Las contraseñas se guardan con scrypt y sal por usuario, nunca en texto plano.
• El login frena la fuerza bruta tras varios intentos fallidos sobre la misma cuenta.
• La API tiene límite de tasa por key (240 requests por minuto) y expone los headers estándar para que un cliente sepa cuánto le queda.
• Cabeceras: frame-ancestors 'none', nosniff y Referrer-Policy estricta.
• Las sesiones usan cookies httpOnly y se pueden cerrar todas de una desde Ajustes.

Backups

La base de cuentas y workspaces se respalda todas las noches a un bucket S3 aparte, con un snapshot consistente y un chequeo de integridad sobre el resultado. Los documentos, al estar en S3 con versionado, se recuperan por versión sin depender del backup.

Inyección de prompts: el riesgo propio de esto

Una memoria compartida que leen agentes es, por diseño, un lugar donde alguien podría dejar instrucciones dirigidas al modelo en vez de a una persona. Es el riesgo específico de esta categoría de producto y preferimos nombrarlo antes que esquivarlo.

Lo que hacemos hoy: si activás la cola de revisión, ningún documento escrito por un agente entra a la memoria sin que una persona lo apruebe, y el diff marca automáticamente los patrones sospechosos —órdenes dirigidas al modelo, pedidos de mandar datos afuera o de revelar credenciales, comandos de shell— para que quien aprueba sepa dónde mirar. No bloqueamos nada automáticamente: la decisión es de la persona.

Límites conocidos

Lo que todavía no tenemos, dicho sin vueltas:

• No hay SSO ni autenticación de dos factores.
• No hay registro de auditoría de acciones administrativas (sí hay historial de cambios por documento).
• No hay cifrado a nivel aplicación por encima del que da S3 y el disco: quien opera la infra puede leer.
• Todavía no hay envío de correos, así que el enlace de recuperación de contraseña se entrega a mano.
• No tenemos certificaciones (SOC 2, ISO 27001) ni las estamos declarando.

Reportar un problema

Si encontrás una vulnerabilidad, escribinos a hola@fluws.com antes de hacerla pública. Respondemos y te contamos qué hicimos.