Esta página describe las prácticas de seguridad que Sinapsis AI implementa actualmente para proteger datos y workflows. Los controles pueden variar según el despliegue, la configuración y la funcionalidad; esta página no constituye una garantía ni una certificación de seguridad.
1. Cifrado en tránsito
Utilizamos TLS para las comunicaciones navegador-servidor, las solicitudes API y las conexiones configuradas con infraestructura y proveedores externos. Los despliegues de producción se configuran para redirigir o rechazar HTTP sin cifrar cuando la configuración del edge lo permite.
2. Cifrado en reposo
Los datos sensibles almacenados por la aplicación se protegen según su tipo:
- API keys — Se almacenan hashes cuando solo es necesario verificar la clave; la clave original no se puede recuperar desde esos hashes
- Credenciales SSO e integraciones — Se cifran antes de almacenarse con claves de cifrado de la aplicación
- Credenciales de despliegue e inferencia — Se cifran antes de almacenarse cuando la ruta de despliegue las persiste
- Contraseñas — Hashes bcrypt con salt por usuario
- Secretos TOTP — Se cifran antes de almacenarse
Las copias de seguridad y volúmenes de disco utilizan los controles de cifrado de la infraestructura seleccionada. En self-hosted, el operador debe configurar esos controles.
3. Aislamiento de tenants
Sinapsis AI es una plataforma multi-tenant. Los datos de cada organización se protegen mediante:
- Consultas y controles de acceso limitados a la organización
- Validación de membresías y roles para recursos de la organización
- API keys y permisos de despliegue por organización
- Límites adicionales de workspace cuando están habilitados
- Rutas de acceso de operadores de plataforma restringidas y auditadas
El aislamiento de tenants es un control lógico de aplicación y base de datos. No afirmamos que todos los despliegues utilicen una base de datos o red física separada.
4. Autenticación y control de acceso
Aplicamos varias capas de autenticación y autorización:
- Tokens JWT en cookies HttpOnly, Secure cuando está habilitado y SameSite=Lax
- Protección CSRF mediante cookies de doble envío y comparación en tiempo constante
- Autenticación de dos factores (TOTP) opcional por usuario
- Autenticación por API key para acceso programático, mostrando la clave una sola vez al crearla cuando aplica
- Control de acceso basado en roles con permisos de Owner, Admin, Member y operadores de plataforma
- Login social mediante proveedores OAuth configurados y PKCE cuando está disponible
- Revocación de sesiones al cerrar sesión y ante eventos de credenciales o controles de cuenta
5. API keys y secretos de conexiones
Las API keys de acceso programático se hashean antes de almacenarse, se limitan a una organización, se identifican mediante un prefijo no secreto y pueden revocarse desde la plataforma cuando está disponible.
Las credenciales de conexiones de software externo, tokens OAuth, secretos SSO y credenciales persistidas de despliegues se cifran en reposo. El plan y la configuración de cada conexión determinan si las credenciales las gestiona Sinapsis o las aporta la organización. La retención del proveedor externo depende de su configuración aplicable.
6. Logs de auditoría
Las acciones administrativas y relevantes para la seguridad se registran en un log de auditoría particionado, incluidos eventos de autenticación y sesiones, cambios de miembros y roles, eventos de API keys, cambios de organización, solicitudes de exportación y borrado, decisiones de compliance y otras operaciones protegidas.
Los registros pueden incluir actor, acción, fecha, IP, user agent, request ID, organización y metadatos del recurso. La retención predeterminada actual es de 365 días, configurable por organización cuando está disponible; los requisitos legales, de seguridad y operativos pueden exigir conservarlos durante más tiempo. Los administradores pueden consultar los logs disponibles en Configuración > Seguridad y datos > Logs de auditoría.
7. Rate limiting y prevención de abusos
El rate limiting respaldado por Redis y las cuotas por plan protegen autenticación, recuperación de contraseña, verificación de dos factores, IA, API keys, exports, despliegues y otros endpoints sensibles o costosos. Los umbrales exactos dependen del endpoint, plan, entorno y configuración operativa, y pueden cambiar según los patrones de abuso y la capacidad.
8. Seguridad de red
- Protección SSRF: Las URLs proporcionadas por usuarios se validan contra rangos IP privados, endpoints de metadatos cloud y puertos peligrosos. El DNS pinning ayuda a evitar ataques de rebinding cuando aplica.
- Listas de IP permitidas: Las rutas compatibles de organización y despliegue pueden restringir el acceso a rangos IP configurados.
- Cabeceras de seguridad: Las respuestas del edge de producción utilizan cabeceras como CSP, X-Frame-Options, X-Content-Type-Options y Referrer-Policy cuando están configuradas.
- CORS: Los orígenes de la API de producción están en una allowlist; no se usan orígenes wildcard para acceso autenticado en producción.
- Segmentación de red: Los servicios del sandbox utilizan redes dedicadas separadas de las rutas principales de la aplicación.
9. Copias de seguridad y recuperación
Las copias de seguridad, restauración y retención dependen del despliegue. Los operadores cloud gestionan el proceso de backup y recuperación de la plataforma; en self-hosted, el operador es responsable de frecuencia, cifrado, pruebas de restauración y recuperación ante desastres.
10. Enmascarado de PII
Cuando está habilitada para una ruta de IA, la capa de enmascarado de PII oculta identificadores compatibles antes de enviar prompts a proveedores de modelos externos. Los patrones actuales incluyen emails, números de la Seguridad Social, tarjetas, teléfonos y direcciones IP.
El enmascarado es orientativo y depende de la ruta. No sustituye la obligación de elegir un proveedor adecuado, configurar su retención y no enviar datos que tu organización no esté autorizada a procesar.
11. Sandbox de ejecución de código
El código Python enviado por usuarios desde code nodes de workflows y agent tools se ejecuta en un sandbox efímero y aislado en contenedor cuando el sandbox está habilitado:
- La red está deshabilitada y el sistema de archivos raíz de ejecución es de solo lectura
- Una política AST compartida bloquea módulos peligrosos, ejecución dinámica y rutas de introspección de Python
- Los contenedores aplican seccomp, eliminación de capabilities, no-new-privileges y límites de procesos
- Se aplican límites de CPU, memoria, sistema de archivos temporal, concurrencia y tiempo de ejecución
- El timeout predeterminado es de 10 segundos en la configuración beta actual
- La entrada y la salida tienen un límite configurable de 1 MB por defecto
El límite actual es un contenedor reforzado. Sinapsis no describe este sandbox como aislamiento de VM o microVM.
12. Analítica de producto y consentimiento
La analítica opcional funciona detrás de la compuerta de consentimiento de analítica. Umami recibe los eventos y páginas configurados, mientras que OpenReplay puede proporcionar telemetría privada de sesiones cuando está configurado. Puedes rechazar o retirar la analítica desde la configuración de cookies. Los fallos de analítica no bloquean el uso del producto.
13. Comunicación de vulnerabilidades
Si descubres una vulnerabilidad de seguridad, comunícala de forma responsable a [email protected]. Confirmaremos la recepción cuando sea posible, dentro de 48 horas, y trabajaremos para resolver las vulnerabilidades confirmadas con prontitud.
14. Infraestructura y configuración de proveedores de IA
En el Servicio cloud actual, la infraestructura principal se aloja en la Unión Europea, actualmente en los Países Bajos. En self-hosted, el cliente controla las decisiones de infraestructura.
Sinapsis AI es independiente del modelo:
- Los modelos y las rutas aprobadas de proveedores están disponibles según el plan y la configuración del despliegue
- El entrenamiento, la retención, el logging, la seguridad y la residencia dependen del proveedor y la ruta seleccionados
- La inferencia local o self-hosted permanece en la infraestructura seleccionada cuando se configura de ese modo
- Los datos de inferencia solo se envían a proveedores o infraestructuras configurados para el workflow, evaluación o trabajo de entrenamiento aplicable
Revisa las condiciones de seguridad, privacidad, tratamiento de datos y retención de cada proveedor antes de enrutar cargas sensibles.
15. Lo que no afirmamos
Por transparencia:
- No tenemos certificación SOC 2 Type II en este momento
- No ofrecemos un SLA garantizado para los planes gratuitos
- No afirmamos realizar pruebas de penetración de terceros con una periodicidad fija
- El cifrado de extremo a extremo de prompts de IA no está disponible; los prompts se procesan en la capa de aplicación antes de enviarse a los proveedores
- El módulo de Compliance no proporciona asesoramiento jurídico, certificación, attestation HIPAA ni conformidad con el Reglamento de IA de la UE
Para preguntas sobre nuestras prácticas de seguridad, contacta con nosotros en [email protected].