Cómo encerrar el código de un agente de IA: subprocess, Docker y microVM, tres niveles de protección

Le diste al agente una herramienta de «ejecutar código Python» y en ese momento tienes no solo un asistente, sino ejecución remota de código, aunque sea a petición del modelo. El modelo puede equivocarse, o puede recibir una instrucción dañina desde una página o un archivo manipulados. Por eso la pregunta no es «si el agente es inteligente», sino «qué podrá alcanzar un programa malicioso cuando se ejecute». Los autores del análisis en Machine Learning Mastery responden de forma práctica: construyen tres sandboxes y lanzan los mismos ataques contra cada una.

Una herramienta, backends intercambiables

La arquitectura es sencilla. El agente conoce una sola herramienta, run_python: recibe una cadena con código y devuelve stdout, stderr y el código de salida. El código del modelo nunca se ejecuta dentro del proceso del propio agente. Se envía a un objeto sandbox con un método run(code), y sirve cualquier clase que tenga ese método. Por eso cambiar el nivel de aislamiento no obliga a tocar la lógica del agente: se sustituye el backend y listo. Un código de retorno distinto de cero se marca como error, y el modelo lo ve y puede corregirse.

Un principio importante del blog de Docker, que los autores aplican a todos los niveles: el acceso a archivos, la política de red y los secretos los define la infraestructura antes de iniciar el agente, no el propio agente.

Tres fronteras

Subprocess es la opción más ligera. Es un proceso hijo con límites de tiempo de CPU, memoria (espacio de direcciones) y tamaño de los archivos que puede escribir. A su alrededor:

• ejecución en modo aislado python -I en una carpeta temporal;
• entorno limpio, sin claves de API ni directorio personal;
• unshare --net, es decir, una red privada vacía;
• salida a archivos, de modo que el límite de tamaño de archivo también protege frente a un torrente de print;
• al agotarse el tiempo, se mata todo el grupo de procesos.

Si el constructor no puede activar el aislamiento de red, falla con un error en lugar de dejar la red abierta en silencio. Si se ejecuta como root, el código se degrada primero al usuario nobody.

Pero este nivel tiene una salvedad honesta: el kernel y el sistema de archivos siguen siendo los del host. El código funciona en tu nombre, sobre tu sistema de archivos, y no oculta tus archivos. El límite de número de procesos cuenta todos los procesos del usuario, por lo que solo tiene sentido para un usuario dedicado; en un portátil normal se omite.

El contenedor Docker añade espacios de nombres y cgroups, pero siguen siendo los mismos procesos sobre el kernel del host. La documentación de Docker dice claramente que, sin ajustes explícitos, un contenedor no tiene límites de recursos, por lo que en la sandbox se fijan la memoria, el número de CPU y el número de procesos (en el ejemplo, 256 MB, una CPU, 64 pids). Y los escapes ocurren: en noviembre de 2025, tres vulnerabilidades en runc permitían salir del contenedor.

La microVM sobre Firecracker (en el ejemplo, a través de E2B) da a cada sandbox su propio kernel tras un hipervisor. Docker lo llama frontera de hardware, y AWS afirma que en Lambda sobre Firecracker el kernel no se comparte entre sesiones. Es la opción más cara en latencia y requiere una cuenta de E2B con clave.

Qué hacer con esto

Los autores prueban cada nivel con programas hostiles idénticos: agotamiento de CPU, memoria, procesos y disco, e intentos de leer archivos y acceder a la red. Después, en bench.py, miden el coste en latencia de reforzar el aislamiento. En la parte disponible del material no hay cifras de las mediciones, así que ejecuta el benchmark en tu propio hardware: la latencia depende mucho del entorno.

La lógica práctica de elección es esta:

• Subprocess sirve para experimentos locales y código en el que casi confías. Requiere Linux o WSL.
• Docker con flags estrictos encaja en herramientas internas donde estás dispuesto a asumir el riesgo de un escape.
• MicroVM es la elección para entradas ajenas y no confiables y para productos multiinquilino, donde un escape supone un incidente.

Y lo principal: no dejes que el agente decida sobre su propia sandbox. Los secretos, la red y los archivos los determina quien despliega la infraestructura. Si quieres una solución ya hecha y no autoconstruida, los autores tienen un artículo aparte sobre cinco sandboxes alojadas; aquí todo se monta a mano para que se vea qué hacen exactamente esas plataformas por dentro.