Higiene empresarial estándar, aplicada con cuidado.

La mayor parte del trabajo de seguridad en una plataforma de este tipo es estándar. Cifrado en reposo. Cifrado en tránsito. Secretos delimitados a workers individuales. Claves aisladas por entorno. Procedimiento documentado de respuesta a incidentes. Programa de divulgación responsable. Nada de esto es novedoso. El trabajo consiste en hacer cada elemento con cuidado, con comportamientos predeterminados de cierre seguro, y sin excepciones en desarrollo.

Esta página describe cómo se implementa cada elemento. La matriz de aplicación completa se encuentra en el documento de ingeniería de seguridad; esta versión es lo que necesita leer para informar a un equipo de seguridad.

Todo el almacenamiento de objetos (Cloudflare R2, AWS S3, MinIO local y Azure a través de un endpoint compatible con S3) está cifrado en reposo usando el AES-256 predeterminado del proveedor de la plataforma. Todo el almacenamiento de Durable Object y base de datos hereda el mismo valor predeterminado. El tráfico entre workers y de worker a almacenamiento utiliza TLS 1.2 o superior, y las llamadas salientes a Anthropic y ElevenLabs negocian TLS 1.3.

Las claves se delimitan por entorno y por worker. El entorno de desarrollo nunca comparte una clave con producción, y los workers del plano de datos nunca comparten claves con los workers del plano operador. El depósito de credenciales de cada espacio de trabajo se sella bajo una clave derivada únicamente para ese espacio de trabajo. Para los despliegues que requieren claves gestionadas por el cliente, una integración KMS en el cloud elegido (AWS KMS, Azure Key Vault o el equivalente de Cloudflare) se configura durante el proyecto.

Cada secreto reside exactamente en un worker. No hay claves HMAC compartidas, no hay tokens portadores copiados, no hay reutilización entre entornos. El worker de ingesta tiene el secreto de firma de webhooks. El worker de operaciones tiene el secreto portador de administrador. El worker motor tiene la clave API LLM. El worker de consultas tiene el secreto portador del lado de lectura. El worker canvas tiene el secreto de mutación de matriz.

Los workers que necesitan comunicarse entre sí utilizan enlaces de servicio de Cloudflare (o el equivalente en AWS, Azure, local). Los enlaces de servicio transportan la identidad del llamante de forma nativa. No hay una clave de firma compartida copiada entre workers. Comprometer el secreto de un worker no se propaga al radio de explosión de otro worker.

Los workers fallan de forma segura cuando un secreto requerido está ausente al inicio. El worker arranca, se niega a servir, y registra el nombre del secreto faltante. No hay una ruta de reserva que sirva silenciosamente con una credencial predeterminada.

La plataforma se bloquea antes de filtrarse. La lista de verificación de cierre seguro se aplica en cada worker, sin excepciones en desarrollo ni en staging:

• Firma HMAC de webhook en cada webhook entrante. Una firma faltante o incorrecta devuelve 401 sin lectura del cuerpo ni escritura en almacenamiento.
• Token portador en cada llamada a la API del operador. Un token faltante, malformado o revocado devuelve 401 sin llamada descendente emitida.
• Verificación de rol en cada ruta autenticada. Un token válido con el rol incorrecto devuelve 403.
• Verificación de propiedad de matriz en cada mutación canvas. El llamante debe ser el propietario de la matriz; de lo contrario, 403. La misma postura de cierre seguro cubre la superficie canvas tal como se entrega.
• Verificación del presupuesto de tokens antes de cada llamada LLM. Exceder el presupuesto devuelve una fila de trazabilidad de presupuesto excedido sin llamada.
• Verificación del hash de prompt antes de cada llamada de enriquecimiento. Una discrepancia de plantilla de prompt falla de forma segura con una fila de trazabilidad prompt_drift. Sin ediciones silenciosas a los prompts desplegados.
• Validación del esquema de salida en cada respuesta LLM. Una salida que no valida falla de forma segura; la respuesta bruta se conserva en el blob de resultado para análisis forense.

Si un desarrollador quiere un indicador de «omitir autenticación para pruebas locales», ese es el momento en que entregamos una vulnerabilidad. El entorno de desarrollo usa un secreto separado con la misma aplicación.

Cada método de consulta en la API de lectura requiere su clave de alcance (identificador de matriz, identificador de organización) como argumento posicional tipificado. Omitirla es un error de compilación de TypeScript. Se verifica en tiempo de compilación, antes de que la autorización en tiempo de ejecución tenga oportunidad.

Cada ruta HTTP incluye la clave de alcance en la ruta, no en un parámetro de consulta. La firma del controlador lo exige. No existe una ruta «listar todo» donde un filtro de inquilino pudiera eliminarse silenciosamente. Cuando la plataforma agrega un segundo alcance de organización (los despliegues actuales son de organización única), el error de compilación identifica cada lugar que necesita actualizarse.

Cada operación que cambia el estado ya escribe en un almacén de solo adición. La ingesta de webhook escribe en el índice del lago de datos. Las ediciones canvas escriben un nuevo blob de versión del plan conservando la versión anterior. Los sobres del motor escriben una fila de trazabilidad para cada llamada LLM: identificador del modelo, conteo de tokens, duración, estado y un puntero al blob de resultado. El gasto del presupuesto incrementa una fila contadora.

No existe una función de «registro de auditoría» separada porque todo el sistema es el registro de auditoría. Un operador que investiga un incidente consulta las tablas existentes. Las respuestas ya están allí. No hay una ruta de eliminación de filas en la plataforma. La revocación del consentimiento se gestiona mediante una lápida que bloquea el acceso a una conversación en lugar de borrar el historial, de modo que el registro de lo ocurrido permanece intacto y a prueba de manipulaciones.

Los incidentes se notifican a una persona de guardia designada. El procedimiento tiene cinco pasos: confirmar el incidente, congelar las credenciales afectadas, tomar una instantánea del estado afectado desde los almacenes de solo adición, identificar el radio de explosión desde las filas de trazabilidad, y ejecutar la remediación. El manual se publica con el compromiso.

La notificación al cliente está vinculada contractualmente. Para un incidente de datos confirmado que afecte datos de encuestados, notificamos al cliente dentro de las 24 horas siguientes a la confirmación. La notificación incluye las marcas de tiempo de la vulneración, el radio de explosión, la remediación realizada, y la pista de auditoría que utilizamos para establecer estos hechos.

Una revisión posterior al incidente se comparte por escrito dentro de los diez días hábiles. La revisión nombra la causa raíz, el cambio arquitectónico que previene la recurrencia, y la verificación que realizamos para confirmar que el cambio se mantiene.

Los investigadores de seguridad que encuentren una vulnerabilidad pueden reportarla a security@nexaintel.ai. Acusamos recibo dentro de los dos días hábiles. Nos comprometemos a proporcionar una corrección o un calendario de mitigación documentado dentro de quince días hábiles para problemas de alta gravedad, treinta días hábiles para problemas de gravedad media. Acreditamos al investigador en el aviso de seguridad a menos que prefiera el anonimato.

No emprendemos acciones legales contra investigaciones de buena fe que sigan el calendario de divulgación. Nos reservamos el derecho de retrasar la divulgación pública hasta que los despliegues afectados estén parcheados.

La plataforma se construye según los requisitos de control que examinan HIPAA, SOC 2 Type II, Loi 25 de Quebec y RGPD. La arquitectura aporta el sustrato para esos controles: despliegue en inquilino, acuerdos de no entrenamiento y no retención con los socios LLM y de voz, la pista de auditoría de solo adición, el mecanismo de lápida para la revocación del consentimiento, y la ubicación de región definida por despliegue.

En un despliegue en inquilino, las certificaciones que importan pertenecen a su infraestructura. La plataforma se ejecuta dentro de la cuenta cloud que usted ya tenía auditada, de modo que su atestación SOC 2, HIPAA o regional la cubre del mismo modo que cubre todo lo demás que usted ejecuta. Para los compradores que desean ayuda, hay disponible un despliegue gestionado en el que Nexa opera una mayor parte del stack bajo contrato.

Las atestaciones de los subprocesadores (Cloudflare, Anthropic, ElevenLabs), nuestro DPA, la lista de subprocesadores y un cuestionario de seguridad vigente están disponibles bajo NDA a través de contacto. Para un despliegue en inquilino, su equipo evalúa la plataforma frente a su propio marco.