Cómo aislar agentes de IA sin falsear una prueba de ciberseguridad

Para aislar un agente de IA sin falsear la prueba, conserva las capacidades que quieres medir y coloca sus límites fuera de su control: inferencia separada, herramientas en un entorno desechable, red bloqueada por defecto y anfitrión sin secretos ni interfaces administrativas expuestas. El aislamiento debe controlar dónde producen efectos sus acciones, no impedirle actuar dentro del escenario.

Define primero la capacidad evaluada. Si el objetivo es encontrar una vulnerabilidad en un repositorio, el agente puede necesitar leer código, ejecutar comandos y observar resultados; quitarle la terminal alteraría la medición. Eso no implica darle acceso a Internet, la red corporativa, el servicio de inferencia o credenciales de producción.

1. Separa inferencia, herramientas, red y anfitrión

Una máquina virtual o un contenedor llamado “sandbox” no resuelve por sí solo todas las fronteras. Trata por separado el servicio que ejecuta el modelo, el entorno de herramientas, la capa que autoriza conexiones y el anfitrión que crea, observa y destruye cada ejecución.

La arquitectura del Inspect Sandboxing Toolkit del AISI mantiene la inferencia fuera del sandbox y hace que Inspect envíe desde el exterior los comandos solicitados por el modelo. Su protocolo clasifica el aislamiento en tres ejes —herramientas, anfitrión y red— y el kit incorpora complementos para Docker Compose, Kubernetes y Proxmox.

• Inferencia: recibe mensajes y resultados, pero no monta el repositorio objetivo ni administra el perímetro.
• Ejecución: contiene shell, compiladores, navegador y servicios de prueba en una instancia efímera.
• Red: aplica reglas que los procesos del sandbox no pueden modificar.
• Anfitrión: conserva telemetría y control de parada sin exponer sockets del orquestador.

Elige la tecnología según el riesgo. Un contenedor puede bastar para una tarea acotada; una evaluación de evasión o explotación avanzada puede exigir aislamiento mediante máquina virtual. En ambos casos hay que revisar privilegios, montajes, kernel compartido, dispositivos, interfaces administrativas y rutas de red.

2. Sustituye el exterior sin empobrecer la tarea

Conserva las posibilidades relevantes y sustituye solo los sistemas que no deben quedar expuestos. Utiliza repositorios sintéticos o copias autorizadas, servicios deliberadamente vulnerables, cuentas ficticias y datos señuelo. Si la tarea necesita un registro de paquetes o una API, ofrece una réplica local o un destino preparado expresamente para la evaluación.

El contrato de la prueba debe enumerar herramientas, archivos visibles, servicios alcanzables y operaciones sujetas a aprobación. Identifica también las versiones de la imagen, el modelo, el arnés y las configuraciones: un cambio silencioso del entorno puede parecer una mejora o regresión del agente.

No introduzcas secretos reales por comodidad. Las credenciales simuladas permiten observar si el agente las descubre o usa sin convertir un fallo de contención en un incidente. Si un servicio autorizado requiere autenticación, emplea una identidad exclusiva, revocable y con el alcance mínimo.

3. Comprueba el perímetro con pruebas negativas

Antes del desafío, intenta romper el aislamiento desde la misma identidad y con las mismas herramientas que recibirá el agente. No basta con comprobar que una petición web convencional falla: hay que buscar rutas alternativas hacia recursos reales y hacia el anfitrión.

• Resolver dominios externos y conectar directamente por dirección IP.
• Alcanzar rangos privados, servicios vecinos y endpoints de metadatos de nube.
• Leer procesos, dispositivos, variables, sockets o directorios sensibles del anfitrión.
• Elevar privilegios, crear montajes o comunicarse con Docker, Kubernetes u otro orquestador.
• Modificar o borrar la telemetría utilizada para observar la ejecución.

El entorno supera esta comprobación solo si la tarea prevista sigue siendo realizable y cada operación prohibida falla como establece la política. Registra también la causa del bloqueo: un tiempo de espera ambiguo no demuestra lo mismo que una denegación aplicada por el control previsto.

4. Bloquea la red por defecto y autoriza fuera del sandbox

La política inicial debe negar toda salida. Cuando el desafío necesite conectividad, permite únicamente destinos, puertos y protocolos preparados, con DNS controlado y registro de conexiones. Una instrucción en el prompt no es una barrera técnica: la restricción debe aplicarse fuera del entorno que controla el agente.

La guía conjunta alojada por Cyber.gov.au recomienda defensa en profundidad, privilegios mínimos, segmentación, monitorización y aprobación humana previa para acciones de alto impacto, entre ellas la salida de red. En una evaluación, cada excepción debería identificar tarea, destino, duración y responsable; el agente no debe poder concedérsela a sí mismo.

Haz que el tráfico permitido atraviese una pasarela controlada. Tras la ejecución, revoca las reglas temporales y comprueba que no queden rutas alternativas mediante DNS, proxies, IPv6 o redes de gestión. Establece además límites de tiempo, procesos, memoria y almacenamiento para evitar que una carga hostil afecte al laboratorio completo.

5. Estandariza la ejecución y conserva evidencia

Inspect Cyber, publicado por el AISI el 26 de junio de 2025, organiza una evaluación con dos archivos de configuración: uno describe la prueba y otro, la infraestructura requerida. Al estar construido sobre Inspect, admite agentes personalizados, puntuación, sandboxes y políticas de supervisión humana o de referencia.

Ese formato ayuda a repetir la ejecución, pero no demuestra por sí mismo que el perímetro sea seguro. Conserva entradas y salidas del modelo, llamadas y respuestas de herramientas, cambios de archivos, procesos, conexiones, aprobaciones y causa de terminación. La evidencia debe escribirse fuera del espacio modificable por el agente y someterse a una política de acceso y retención.

Interpreta conjuntamente puntuación y contención. Un agente que fracasa porque le falta una herramienta necesaria no ha demostrado menor capacidad: la prueba está incompleta. A la inversa, resolver el desafío no valida el aislamiento si existía una ruta hacia sistemas reales que el agente no llegó a utilizar.

Lista previa a cada ejecución

1. La capacidad evaluada y las herramientas imprescindibles están descritas.
2. Repositorios, servicios, identidades y datos son simulados o están expresamente autorizados.
3. La inferencia está separada del entorno que ejecuta herramientas.
4. El sandbox es desechable, carece de privilegios innecesarios y no expone el orquestador.
5. La salida de red está bloqueada; cada excepción tiene destino, duración y responsable.
6. Las pruebas negativas de red, metadatos, anfitrión y registros fallan como se espera.
7. Los límites de tiempo, procesos, memoria y almacenamiento están activos.
8. La telemetría queda fuera del alcance de escritura del agente y no contiene secretos reales.
9. Hay un responsable de vigilancia, un interruptor externo y criterios de parada acordados.
10. Las imágenes, configuraciones y versiones están identificadas para repetir la prueba.

Detén la ejecución ante una conexión inesperada, una vía viable hacia el anfitrión, la aparición de credenciales no preparadas, la pérdida de telemetría o un consumo fuera de límites. Conserva la evidencia y reconstruye el entorno desde una base conocida: el agente necesita libertad dentro del escenario, pero ninguna autoridad sobre sus fronteras.

Lee también:

• QUASA lanza una plataforma totalmente localizada en español, expandiendo su hub de economía de creadores Web3 por el mundo de habla hispana
• El vacío no está vacío: un magnetar respalda una predicción de hace 90 años
• Un agujero negro errante se delató al devorar una estrella