Seguridad

1. Nuestro enfoque

NeuralOS es una plataforma operada por Klinworks, LLC donde personas y equipos trabajan con agentes de IA, automatizaciones y aplicaciones. Eso significa que custodiamos información valiosa: tu cuenta, el contenido de tu espacio de trabajo y, a menudo, las credenciales con las que tus agentes actúan en otros servicios.

Aplicamos defensa en profundidad: varias capas de protección independientes, de modo que si una falla, las demás siguen conteniendo el riesgo. En esta página describimos solo medidas que ya aplicamos en el producto. Lo que todavía es un objetivo lo indicamos expresamente como tal.

Esta página complementa la Política de privacidad, la Política de uso de IA y la lista de subencargados del tratamiento.

2. Infraestructura

NeuralOS se apoya en proveedores de infraestructura reconocidos en lugar de operar centros de datos propios. La lista nominal completa está en Subencargados.

• Cabeceras de seguridad: el API aplica cabeceras HTTP endurecidas y una política de CORS restringida a nuestros orígenes.
• Límites de uso: el API limita la frecuencia de peticiones con un almacén compartido, de modo que el límite se mantiene aunque haya varias réplicas en marcha.
• Mínimo privilegio: las credenciales de infraestructura viven solo en variables de entorno del proveedor; nunca en el código ni en la base de datos.

3. Cifrado

• En tránsito: las conexiones con neuralos.io y con el API usan HTTPS/TLS; las peticiones sin cifrar se redirigen a HTTPS.
• En reposo: la base de datos y el almacenamiento de archivos están cifrados en reposo por nuestro proveedor de datos.
• Secretos a nivel de aplicación: además del cifrado del proveedor, ciframos nosotros mismos los datos más sensibles con AES-256-GCM (cifrado autenticado) antes de guardarlos.
• Cifrado de sobre: cada secreto recibe su propia llave de datos aleatoria, que a su vez se envuelve con una llave maestra. Así podemos rotar llaves maestras sin exponer los datos, y una llave de datos comprometida afecta a un único secreto.
• Atado al contexto: cada secreto cifrado queda ligado criptográficamente a su espacio de trabajo o usuario; copiado a otro contexto, simplemente no se descifra.
• Fallo cerrado: si la verificación de integridad falla, la operación se rechaza; nunca se devuelve un dato parcial.

4. Llaves propias (BYOK) y credenciales de integraciones

Puedes conectar tus propias llaves de proveedores de IA (BYOK, «trae tu propia llave») y credenciales de integraciones de terceros. Las tratamos como el dato más sensible de la plataforma:

• se cifran con una llave específica de tu espacio de trabajo antes de almacenarse;
• no se muestran completas de nuevo tras guardarlas ni se escriben en los registros;
• solo se descifran en el momento de usarlas para la llamada que las necesita;
• puedes revocarlas o sustituirlas en cualquier momento desde tu espacio de trabajo.

Las llaves maestras de cifrado nunca se guardan en la base de datos ni en el repositorio de código, y un detector automático de secretos bloquea cualquier cambio que intente incluir uno.

5. Autenticación y control de acceso

Tu cuenta

• Verificación en dos pasos (2FA): con cualquier aplicación TOTP. El secreto se guarda cifrado y los códigos de respaldo se guardan como hash y son de un solo uso.
• Sesiones revocables: puedes ver tus sesiones activas y cerrar una o todas. Al cambiar la contraseña se cierran las demás sesiones y te avisamos por correo.
• Anti-bots y anti-enumeración: el registro y el acceso están protegidos con Cloudflare Turnstile, y el registro no revela si un correo ya tiene cuenta.
• Gestión de credenciales: la autenticación la gestiona Supabase Auth; nunca almacenamos contraseñas en claro.

Tu espacio de trabajo

• Aislamiento por fila: las tablas con datos de clientes tienen activada la seguridad a nivel de fila (RLS) de PostgreSQL, de modo que la base de datos solo devuelve filas del espacio de trabajo al que perteneces.
• Roles: cada miembro tiene un rol (propietario, administrador, miembro u observador) y el API comprueba ese rol antes de cada acción sensible.
• Acceso interno: el personal de Klinworks, LLC accede a datos de clientes solo cuando es necesario para prestar soporte, investigar un incidente o cumplir la ley.

6. Seguridad de los agentes de IA

Los agentes pueden leer, escribir y actuar en tu nombre. Por eso los limitamos por diseño:

• Permisos explícitos: un agente solo usa las herramientas, integraciones y fuentes de conocimiento que tú le concedes.
• Lo importante espera tu firma: las acciones con impacto (por ejemplo, gastos o envíos externos) pueden requerir aprobación humana, y cada aprobación o rechazo queda registrado con quién la decidió.
• Contenido no confiable: tratamos el contenido externo que lee un agente (webs, documentos, correos) como datos, no como órdenes, para reducir el riesgo de inyección de instrucciones. Ninguna defensa es perfecta: revisa lo que un agente propone antes de aprobarlo.
• Proveedores de modelos: los prompts se envían a los proveedores indicados en Subencargados solo para generar la respuesta. Más detalles en la Política de uso de IA.

7. Desarrollo seguro

Cada cambio de código del API pasa por un circuito de integración continua que debe estar en verde antes de desplegarse:

1. Detección de secretos (gitleaks): ninguna llave ni contraseña puede entrar en el repositorio.
2. Control de seguridad de la base de datos: revisa los avisos de seguridad de Supabase (por ejemplo, tablas sin RLS) y bloquea el cambio si encuentra alguno.
3. Comprobación de tipos estricta, lint y formato.
4. Pruebas automatizadas con umbrales mínimos de cobertura, incluidas pruebas de integración contra una base de datos real.
5. Build de producción.

La aplicación web tiene además sus propios guardianes que verifican los contratos entre la web y el API. Los cambios en el esquema de datos se hacen solo mediante migraciones versionadas.

8. Monitorización y registro

• Registro de auditoría de solo anexado: las acciones relevantes (cambios de rol, facturación, agentes, automatizaciones…) se anotan con quién, qué y cuándo. Un disparador en la propia base de datos impide modificar o borrar esas entradas, incluso con acceso directo.
• Libro de pagos inmutable: los movimientos de saldo y pagos se registran también de forma append-only.
• Vigilancia de la salud: un guardián externo comprueba cada 15 minutos que la web y el API responden, y cada 6 horas el flujo completo de acceso, como lo haría un usuario real. Cualquier incidente queda registrado de inmediato para el equipo.
• Errores: usamos Sentry para detectar y diagnosticar fallos, con datos técnicos limitados.
• Estado del servicio: puedes consultarlo en /status.

9. Respuesta a incidentes

Si detectamos o nos reportan un incidente de seguridad, seguimos este proceso:

1. Detección y evaluación: confirmamos el alcance y la gravedad.
2. Contención: aislamos los sistemas afectados, revocamos credenciales expuestas y rotamos llaves si procede.
3. Notificación: si un incidente afecta a tus datos personales, te avisamos sin demora indebida y, cuando corresponda, a las autoridades competentes dentro de los plazos legales (por ejemplo, 72 horas en el RGPD).
4. Recuperación: restauramos el servicio y verificamos que la causa está corregida.
5. Aprendizaje: analizamos la causa raíz y añadimos controles para que no se repita.

10. Divulgación responsable

Agradecemos a quienes investigan de buena fe y nos ayudan a proteger a nuestros usuarios. Si encuentras una vulnerabilidad en neuralos.io, sus subdominios o el API de NeuralOS, escríbenos a ceo@neuralos.io con:

• una descripción del problema y su impacto potencial;
• los pasos para reproducirlo (y, si puedes, una prueba de concepto);
• tu forma de contacto preferida.

Te pedimos que: no accedas, modifiques ni borres datos de otras personas; no degrades el servicio (nada de pruebas de denegación de servicio, spam ni ingeniería social a nuestro equipo o usuarios); uses solo cuentas propias o de prueba; y nos des un plazo razonable para corregir antes de publicar nada.

Nos comprometemos a: acusar recibo, mantenerte informado del avance, reconocer tu aportación si lo deseas, y no emprender acciones legales contra la investigación realizada de buena fe conforme a estas reglas. No tenemos por ahora un programa de recompensas económicas.

11. Cumplimiento y certificaciones

Solo afirmamos certificaciones que tenemos de forma efectiva.

Nuestros proveedores de infraestructura principales cuentan con sus propias certificaciones, que puedes consultar en sus centros de confianza. Cuando superemos una auditoría, lo reflejaremos aquí.

12. Tu parte de la seguridad

La seguridad es compartida. Nosotros protegemos la plataforma; tú controlas quién entra en tu cuenta y qué pueden hacer tus agentes. Te recomendamos:

• activar la verificación en dos pasos y guardar tus códigos de respaldo en un lugar seguro;
• usar una contraseña única y no compartir tu cuenta;
• conceder a cada miembro y a cada agente solo los permisos que necesita;
• revisar las acciones que un agente propone antes de aprobarlas;
• rotar tus llaves BYOK si sospechas que se han expuesto, y cerrar las sesiones que no reconozcas;
• avisarnos de inmediato si detectas actividad sospechosa.

Si construyes aplicaciones con NeuralOS, eres responsable de la seguridad de su lógica y de los datos de tus propios usuarios finales.

13. Cambios en esta página

Mejoramos nuestras medidas de seguridad de forma continua y actualizaremos esta página para reflejarlo. La fecha de la última actualización figura en la cabecera. Si un cambio reduce de forma relevante el nivel de protección descrito, lo comunicaremos con al menos 30 días de antelación.

14. Contacto

Para cualquier consulta de seguridad, para reportar una vulnerabilidad o un incidente, escribe a ceo@neuralos.io. Si es urgente, incluye URGENTE en el asunto.

Klinworks, LLC · sociedad de responsabilidad limitada (LLC) constituida en el Estado de Delaware, EE. UU. · número de registro 10704723.