Defensa en capas, con las cartas boca arriba.

1. El modelo de amenazas

Antes de las defensas va la lista de lo que defendemos: qué activo, contra qué amenaza y con qué mitigación. Si algo no está en esta tabla, es que todavía no lo hemos resuelto y lo decimos en los límites.

2. Aislamiento entre personas

Cada cuenta trabaja dentro de su propia celda, con memoria y CPU limitadas. No hay carpeta compartida ni puerta entre espacios: el aislamiento no depende de una contraseña, sino de la arquitectura. Tres capas independientes lo sostienen: el puerto interno solo escucha en la dirección local del servidor; el servicio de la celda solo confía en el proxy local; y una regla de cortafuegos descarta el tráfico de los contenedores hacia la gestión de la máquina.

Cuando una tarea ejecuta herramientas, lo hace dentro de ese mismo espacio acotado. Nada corre «en el servidor a la vista de todos». El detalle completo está en la especificación de arquitectura.

3. Identidad y cuentas

• Contraseñas con cifrado fuerte; nunca en texto plano.
• Límite de intentos fallidos por correo y por conexión, con bloqueo temporal.
• Verificación en dos pasos (aplicación de códigos) y códigos de respaldo de un solo uso.
• Sesiones activas visibles y cierre individual o total; cambiar la contraseña cierra las demás sesiones.
• Cookies de sesión protegidas y solo por conexión cifrada.

4. Red y superficie expuesta

• Las celdas no tienen salida libre a internet: solo hablan con los servicios internos que necesitan (inferencia y búsqueda).
• La búsqueda web sale por una red privada entre servidores dedicados, nunca por proxies de terceros.
• Los puertos internos escuchan únicamente en la máquina local. La administración del servidor entra por llave, nunca por contraseña.
• El cortafuegos permite solo lo necesario: web pública, cifrado y administración por llave, no por contraseña.
• El sitio público sirve cabeceras de seguridad estrictas (política de contenido, HSTS, sin incrustación en marcos ajenos).

5. Contenido hostil: inyección y extracción

Un riesgo real de los asistentes agénticos es que un contenido malicioso (una página, un archivo) intente dar órdenes al sistema. El diseño trata todo material como datos, nunca como instrucciones; los espacios de trabajo están confinados a la carpeta del usuario; y los límites de recursos evitan que un contenido empuje al sistema fuera de su carril.

La otra cara es la extracción: alguien conversando para que el asistente revele sus instrucciones internas o detalles del backend. Esa superficie está bloqueada por diseño, y la regla de producto la refuerza: nada del interior del sistema se narra ni se muestra.

6. Operación

• Todo el tráfico viaja cifrado en tránsito (HTTPS y WSS).
• Los secretos críticos viven fuera del código y fuera del alcance de los usuarios; el repositorio nunca los contiene.
• Actualizaciones de seguridad y limpiezas automáticas diarias, con verificación antes de entrar en servicio.
• Monitoreo de salud pieza por pieza; ante fallos, los espacios se recuperan sin exponer datos de nadie.
• Las copias de seguridad técnicas son de corto plazo, rotan solas y no se usan para ningún otro fin.

7. Divulgación responsable

El mismo canal está publicado en /.well-known/security.txt del dominio, como manda la costumbre.

8. Límites honestos

Ningún servicio serio puede prometer invulnerabilidad absoluta. Lo que sí podemos: diseño defensivo, aislamiento real, revisión continua, respuesta rápida y honestidad cuando algo pase. También declaramos lo que no cubrimos: el aislamiento es de contenedor, no de máquina dedicada; la operación corre en una sola región; y la cadena de proveedores externos se gobierna por contrato, no por auditoría interna.

Última actualización: 13 de octubre de 2026.