Seguridad y confianza

No. Cada empresa trabaja en su propio espacio (workspace) y la base de datos verifica en cada lectura y escritura que la persona pertenece a ese espacio, no solo la pantalla. Aunque alguien intentara consultar la base directamente, solo obtiene lo suyo.

Refuerzos en aplicación: impedir mover registros propios a otro workspace y validar referencias cruzadas en la base de datos.

Para tu equipo de seguridad

• Row Level Security (RLS) de PostgreSQL activa en las 54 tablas, con funciones de pertenencia y rol (miembro, editor, administrador) evaluadas en la base de datos.
• Los usuarios anónimos no tienen acceso a ninguna tabla con datos de clientes.
• Las acciones del servidor validan la sesión y el rol antes de actuar y filtran siempre por el workspace verificado.

Solo con tu clave y, si lo activas, con el código de tu celular (doble factor). Puedes ver dónde está abierta tu cuenta y cerrar sesión en todos los dispositivos con un clic.

Refuerzo en aplicación: exigir el doble factor también dentro de la base de datos.

Para tu equipo de seguridad

• Autenticación gestionada por Supabase Auth: contraseñas con hash bcrypt, nunca guardadas en texto.
• Doble factor (TOTP: Google Authenticator, Microsoft Authenticator, etc.) exigido en las páginas, las acciones del servidor y las API.
• Inicio de sesión con Google o Microsoft (SSO) opcional.
• Verificación anti-bots de Cloudflare Turnstile en registro, ingreso y recuperación de contraseña.
• Registro de sesiones (dispositivo, navegador, ciudad aproximada) y cierre de sesión global.

No. Toda la comunicación va cifrada, como en la banca en línea, y el navegador tiene prohibido conectarse sin cifrado.

Para tu equipo de seguridad

• HTTPS con TLS 1.2 o superior en todas las conexiones.
• HSTS de 2 años con preload: el navegador nunca usa HTTP.
• Conexiones a la base de datos y a los proveedores también cifradas.

La información está cifrada en los servidores. Además, las llaves y contraseñas de terceros que guardas (IA, correo) tienen un segundo cifrado propio, y los enlaces secretos solo se guardan como huella imposible de revertir.

Para tu equipo de seguridad

• Cifrado en reposo AES-256 del proveedor de base de datos (Supabase sobre AWS).
• Llaves de IA propias, contraseñas SMTP y tokens de buzones: cifrado adicional AES-256-GCM con llave fuera de la base de datos.
• Tokens de invitaciones, firmas, enlaces compartidos, portal de proveedores y llaves de API: solo su hash SHA-256.

No hay código oculto ni que se descargue de sitios desconocidos. Todo el código pasa por revisiones automáticas antes de publicarse, y el navegador solo ejecuta los scripts autorizados por la aplicación.

Para tu equipo de seguridad

• Sin eval, sin código ofuscado y sin HTML insertado sin escapar.
• Política de seguridad de contenido (CSP) estricta con nonce por petición: solo se ejecutan scripts propios, Cloudflare Turnstile y Google Analytics (este último solo si aceptas la analítica).
• Dependencias del registro oficial de npm con archivo de bloqueo; Dependabot propone actualizaciones de seguridad cada semana.
• Integración continua en cada cambio: tipos, lint, pruebas unitarias y de navegador, accesibilidad y npm audit.

No. Todo lo que se escribe o se importa se valida y se trata como texto, nunca como instrucciones.

Para tu equipo de seguridad

• Consultas parametrizadas (PostgREST): no hay SQL armado con texto del usuario.
• Validación de datos con esquemas en el servidor; sin asignación masiva de campos.
• Exportaciones a Excel y CSV protegidas contra inyección de fórmulas.
• Archivos: extensiones permitidas, máximo 25 MB, rutas generadas por el servidor y descarga con enlaces firmados de 60 segundos.
• Encabezados: X-Frame-Options DENY, nosniff, Referrer-Policy y Permissions-Policy restrictiva.

No se pueden adivinar: son claves aleatorias muy largas. Los reportes compartidos y las firmas vencen y se pueden revocar, y para firmar se pide un código enviado al correo del firmante.

Para tu equipo de seguridad

• Tokens de 24 a 32 bytes aleatorios guardados solo como hash.
• Firma electrónica con código por correo (guardado con llave secreta del servidor) que se anula tras 5 intentos fallidos, evidencia de IP, fecha, dispositivo y huella del contenido (Ley 527 de 1999).
• Redirecciones solo a rutas internas de la aplicación.

No. CIOManager nunca entra a tu red: los datos llegan cuando tú los envías (archivo, enlace publicado o API con una llave que tú creas y revocas). No necesitas abrir puertos ni dar usuarios de tus sistemas.

Para tu equipo de seguridad

• API de ingreso con llaves por workspace (32 bytes, guardadas como hash, revocables), límite de 120 peticiones por minuto y tamaño máximo por envío.
• El servidor se niega a conectarse a direcciones privadas, locales o de metadatos de la nube (protección SSRF) en enlaces sincronizados y servidores de correo.
• Webhooks verificados con firma HMAC o Svix, comparación en tiempo constante y ventana anti-repetición.

A la IA solo va el texto o el audio que tú le pides procesar, nunca la base de datos completa ni datos de otras empresas. Si una consulta es sensible, usa proveedores de pago o escribe sin nombres propios.

Con llaves gratuitas, algunos proveedores (por ejemplo, el plan gratis de Gemini) pueden usar el contenido para mejorar sus modelos. Para información confidencial usa llaves de pago, que no lo hacen.

Para tu equipo de seguridad

• La IA no tiene acceso directo a la base de datos: recibe solo el contexto que la pantalla le envía, ya filtrado por tus permisos.
• Proveedores: Groq, Google Gemini, OpenRouter y DeepSeek (y las llaves propias que conectes, cifradas).
• El texto de las consultas no se guarda, salvo en tu historial personal, que puedes borrar. Se registra el consumo (proveedor, propósito y tokens).

Puedes exportar toda tu información a Excel o JSON cuando quieras. Las copias de seguridad diarias automáticas se activan con el plan de base de datos de pago.

Las copias diarias automáticas se activan al pasar la base de datos al plan Pro.

Para tu equipo de seguridad

• Exportación de cada módulo a Excel y de los datos personales a JSON.
• Infraestructura administrada con alta disponibilidad (Vercel y AWS).
• Monitoreo de errores y de salud de la aplicación con alertas al administrador.

La administración de la plataforma ve lo necesario para operar el servicio (cuentas, planes, pagos, uso y reportes de soporte), no el contenido de tus proyectos, registros, documentos ni reuniones.

Refuerzo en aplicación: el rol de administrador se validará contra el correo confirmado en el sistema de autenticación.

Para tu equipo de seguridad

• Administradores de plataforma limitados a cuentas definidas; la consola de administración alerta si no tienen doble factor activo.
• Las reglas de la base de datos no dan a la administración acceso al contenido de los workspaces.

Sí. Hay política de tratamiento, autorización expresa, registro de consentimientos, solicitudes de consulta, corrección y supresión, descarga de tus datos y eliminación de la cuenta.

Para tu equipo de seguridad

• Exportación de datos personales en JSON (derecho de acceso y portabilidad).
• Solicitudes Habeas Data con plazos legales visibles para el administrador.
• Transferencia internacional declarada: servidores en Estados Unidos (ver proveedores).
• Analítica de Google solo con consentimiento y sin datos del trabajo; medición propia sin cookies ni IP.

Cualquier persona puede reportar una vulnerabilidad al contacto de seguridad publicado. Los errores de la aplicación se monitorean con alertas, y si un incidente afectara tus datos te avisaríamos por correo y en la app.

Para tu equipo de seguridad

• Archivo security.txt estándar en /.well-known/security.txt.
• Monitor de errores con agrupación, alerta de regresiones y datos sensibles ocultos en los registros.
• Bitácora de actividad por workspace.