Un agente de IA que escribe y ejecuta su propio código solo es seguro en la medida en que lo sea el entorno en el que se ejecuta ese código. En un tutorial publicado por Machine Learning Mastery, el autor muestra cómo aislar este código en tres niveles: un subproceso limitado, un contenedor Docker reforzado y una microVM Firecracker, y luego compara su seguridad y latencia.
- El código de un agente de IA solo es seguro si lo es su entorno de ejecución.
- El subproceso comparte el kernel y los archivos del anfitrión, así que solo sirve para código de confianza.
- El contenedor Docker debería bloquear los seis ataques, pero sigue compartiendo el kernel del anfitrión.
- La microVM da a cada entorno su propio kernel y es imprescindible para código de varios usuarios y secretos.
El subproceso es el nivel más ligero: se trata de un proceso hijo cuyo tiempo de cálculo, memoria y tamaño de archivos están limitados, pero que comparte el kernel y los archivos de la máquina anfitriona. Un contenedor añade espacios de nombres y grupos de control (cgroups), pero sigue siendo un conjunto de procesos sobre el kernel del anfitrión. El artículo recuerda que en noviembre de 2025, tres vulnerabilidades del motor de ejecución runc permitieron a atacantes escapar de contenedores. Una microVM, en cambio, proporciona a cada entorno su propio kernel, detrás de un hipervisor, el software que ejecuta máquinas virtuales.
El dispositivo se basa en una sola herramienta, run_python, puesta a disposición del agente. Cada código producido por el modelo pasa por un objeto «sandbox» dotado de un método run(code), de modo que cambiar el nivel de aislamiento no modifica el agente. El tutorial requiere Python 3.10 o más reciente, un sistema Linux o WSL para el nivel de subproceso, Docker para el contenedor, y una cuenta junto con una clave API de E2B para la microVM. Una clave API de Anthropic es útil para el agente, pero puede evitarse para las pruebas.
Seis ataques idénticos contra cada nivel
Para comparar los tres niveles, se ejecutan los mismos seis programas hostiles: un bucle infinito, una asignación de 512 MB de memoria, un «fork flood» de 200 procesos, la escritura de un archivo de 50 MB, la lectura de un falso archivo de credenciales y la conexión a un falso servicio interno. Un ataque se considera bloqueado cuando la palabra testigo no aparece en la salida, o, para el bucle infinito, cuando la ejecución expira.
En el nivel de subproceso, ejecutado con un usuario Linux estándar, cuatro ataques son bloqueados y dos pasan. El límite de procesos solo se aplica a un usuario dedicado, por lo que el fork flood está permitido, y el archivo de credenciales falsas sigue siendo legible porque el código se ejecuta bajo la identidad del usuario. El autor concluye que este nivel es adecuado principalmente para código en el que se confía.
Para el contenedor Docker, el autor indica que, con las opciones elegidas, Docker debería bloquear los seis ataques, ya que el contenedor no tiene red, su sistema de archivos no contiene los archivos del usuario y se aplican límites de memoria, procesos y disco. En una microVM, los ataques a la memoria, procesos y disco pueden alcanzar los límites de la máquina virtual, pero permanecen confinados a ella, y el archivo secreto y el servicio local no existen en ella.
Latencia y elección del nivel
El subproceso debería ser el más rápido, ya que solo lanza Python. Para los otros dos niveles, el autor precisa que las cifras publicadas son afirmaciones y no garantías: un artículo citado indica que E2B arranca en unos 150 ms, mientras que AWS y Docker describen lanzamientos casi instantáneos para sus productos de microVM. El script bench.py permite medir, en la propia máquina, la mediana y el tiempo más largo en diez ejecuciones de un programa print(1).
El autor recomienda reservar el subproceso para código de confianza, como scripts de desarrollo personales, y el contenedor reforzado para casos en los que se controla el anfitrión y los riesgos son bajos, asegurándose de mantener runc actualizado. La microVM es imprescindible para código proveniente de múltiples usuarios, para todo lo relacionado con secretos, y cuando el agente debe construir y ejecutar contenedores por sí mismo, algo que los contenedores clásicos gestionan mal, según Docker. Docker lanzó sus Docker Sandboxes sobre microVM en abril de 2026, y AWS ofrece Lambda MicroVMs que conservan su estado hasta 8 horas y se suspenden cuando están inactivas. Según Docker, los archivos, las reglas de red y los secretos deben ser definidos por la infraestructura, y no por el agente, antes de su ejecución.
