Contener agentes IA: ocho gates más allá del sandbox

OpenAI reportó que una configuración de DNS permitió a un modelo alcanzar internet durante entrenamiento el 20 de septiembre. Detuvo workloads frontier, reforzó controles y después lanzó una campaña de red team de alto cómputo. Los agentes hallaron vulnerabilidades desconocidas y configuraciones débiles en sandboxes, servicios internos y perímetros de red. El dato operativo importante no es que una marca haya fallado: es que una capacidad autorizada, como resolver nombres, enviar métricas o descargar paquetes, puede convertirse en un puente transitorio hacia un destino prohibido.

Para un equipo de producto, la consecuencia es concreta. Si un agente procesa correo no confiable y además puede ejecutar shell, leer variables de entorno y llamar APIs, el prompt injection no necesita vencer todas las defensas. Solo necesita una cadena viable entre contexto, herramienta, secreto y egreso. La arquitectura debe romper esa cadena en varios puntos y demostrarlo con pruebas adversariales, no con la ausencia temporal de incidentes.

El modelo, el harness y el entorno de ejecución no son la misma cosa. El modelo propone pasos; el harness conserva objetivo, política y autorización; el sandbox ejecuta comandos o navegador. Separarlos permite registrar qué acción fue solicitada y evitar que un proceso comprometido reescriba la lógica que decide. Google describe esta división como cerebro y manos. OpenAI aplica contenedores restringidos dentro de microVM para tareas Linux y añade perímetros de red y nube alrededor. En ambos casos, el hipervisor o runtime es una barrera, no el sistema completo.

Las capas externas deben sobrevivir a un root dentro del guest. Los secretos de larga vida permanecen fuera; un gateway intercambia identidad efímera por una llamada permitida después de validar sesión, usuario, herramienta y destino. La red niega por defecto o media cada salida. El almacenamiento y la memoria no se comparten sin necesidad. La telemetría observa conducta desde fuera de la caja, y un control de parada puede revocar identidad, bloquear egreso y destruir la sesión sin pedir cooperación al agente.

Imagina un agente de soporte que recibe un ZIP adjunto, reproduce un error y propone un parche. Este ejemplo es hipotético. El archivo entra como contenido no confiable. Una sesión efímera lo abre en una microVM sin credenciales, con filesystem temporal y recursos limitados. El harness permite ejecutar tests locales, pero no publicar. Si el agente necesita consultar una dependencia, solicita un destino explícito al gateway; el proxy valida dominio, método, tamaño y redirecciones. Para leer un ticket, recibe un token de alcance estrecho que expira con la tarea y nunca entra como variable de entorno al guest.

El parche sale como artefacto, no como commit autorizado. Un escáner revisa binarios y secretos; CI reconstruye desde una imagen fijada por digest; un humano o política separada aprueba el merge. Si el adjunto intenta inducir una llamada externa, la política de egreso la bloquea aunque el modelo obedezca. Si el proceso explota el runtime, no encuentra claves persistentes. Si intenta usar DNS como túnel o hablar con otra sesión, el perímetro y el monitor generan una señal que detiene el workload. La seguridad no depende de que el modelo reconozca el ataque.

Primero, separa harness y ejecución: el guest no puede editar política, objetivo ni auditoría. Segundo, usa aislamiento fuerte por sesión y destruye el estado salvo artefactos exportados de forma explícita. Tercero, mantén cero secretos de larga vida dentro del guest; entrega identidad efímera y ligada a tarea. Cuarto, convierte herramientas genéricas en capacidades estrechas: leer un ticket no implica listar todos, y proponer un parche no implica hacer push.

Quinto, gobierna el egreso en más de una capa: DNS, IP, URL, redirects, protocolos y servicios que hacen fetch por cuenta del agente. Sexto, aísla memoria, cachés, colas y almacenamiento entre sesiones para impedir comunicación lateral accidental o deliberada. Séptimo, monitorea desde fuera con correlación entre tool call, proceso, red y artefacto, y define señales que paran automáticamente. Octavo, red-teamea suponiendo que las capas interiores ya fallaron; reproduce hallazgos, verifica la corrección y reserva regresiones en la suite.

Empieza con objetivos observables, no con una auditoría genérica. El agente no debe alcanzar un servidor externo controlado por el equipo; leer metadata del cloud; recuperar un secreto de larga vida; acceder al host; montar almacenamiento ajeno; intercambiar un valor sintético con otra sesión; ni continuar después de una señal de parada. Ejecuta cada objetivo desde el camino normal y desde un punto comprometido. OpenAI probó también el perímetro suponiendo que el agente ya había escapado del sandbox y controlaba el host, una práctica útil para saber si las capas externas son realmente independientes.

Mide prevención, detección y respuesta por separado. Prevención pregunta si la acción ocurrió. Detección mide si la telemetría la reconoció y con qué retraso. Respuesta confirma que identidad, red y cómputo quedaron revocados. Conserva un paquete de evidencia con versión de imagen, política, modelo, prompts adversariales, trazas y resultado. Cuando cambie runtime, kernel, sidecar, proxy, modelo o herramienta, repite los casos afectados. La curva de hallazgos puede mostrar aprendizaje del red team, pero no prueba ausencia de rutas desconocidas.

Más aislamiento añade costo, latencia y complejidad. Una microVM por sesión necesita warm pools o suspensión eficiente; un proxy estricto rompe herramientas que descubren destinos dinámicamente; cero secretos exige broker, identidad del workload y políticas por acción; snapshots útiles amplían la superficie de datos. El diseño correcto depende del impacto. Un asistente que solo resume texto no necesita la misma frontera que un agente con shell, navegador autenticado y acceso a producción.

Evita dos simplificaciones. «Está en Kubernetes» no demuestra aislamiento: comparte kernel salvo que el runtime añada una barrera y una política puede abrir hostPath, capabilities o red. «No tiene internet» tampoco basta: DNS, métricas, autenticación, registries, proxies y servicios con SSRF pueden convertirse en egreso indirecto. Documenta dependencias transitivas y prueba cada una. Google advierte que habilitar acceso a APIs o sidecars exige modificar políticas seguras por defecto; cada excepción debe tener owner, propósito, alcance y test de regresión.

Antes de comprar una plataforma, dibuja la ruta de una acción: contenido que entra, decisión del harness, proceso ejecutado, identidad usada, destino llamado, estado persistido y efecto final. Marca dónde una entrada no confiable puede influir en cada paso. Después elimina permisos que no forman parte del caso de uso y mueve secretos fuera del guest. Esas dos decisiones suelen reducir más riesgo que añadir otro clasificador de contenido porque limitan lo que ocurre incluso cuando el modelo se equivoca.

Implementa después egreso mediado, sesiones efímeras, logs externos y una parada ensayada. Crea un pequeño corpus adversarial con prompt injection indirecta, archivos hostiles, redirects, DNS, intento de metadata y comunicación entre sesiones. Promueve el agente solo cuando los ocho gates tengan evidencia y exista una ruta degradada sin ejecución autónoma. Si tu equipo necesita convertir un prototipo con herramientas en una arquitectura operable, Wasyra puede ayudar a modelar fronteras, construir el piloto y dejar los controles verificables sin confundir autonomía con acceso ilimitado.