Entornos de ejecución aislados para agentes de IA: arquitectura, riesgos y patrones del mundo real.

Inicio » Python » Entornos de ejecución aislados para agentes de IA: arquitectura, riesgos y patrones del mundo real.

Permitir que los agentes de IA ejecuten código, modifiquen archivos, abran navegadores y accedan a las API los transforma de una simple función de autocompletado en algo mucho más parecido a un ingeniero junior con permisos de administrador en una máquina. Ese poder adicional es precisamente lo que los hace parecer mágicos, y también lo que los hace peligrosos. Un agente mal configurado o con errores puede borrar una base de datos, filtrar una clave API a internet o implementar una versión defectuosa en producción sin comprender realmente qué salió mal.

La verdadera pregunta ya no es "¿cuán preciso es el modelo?", sino "¿qué puede lograr cuando se equivoca, es engañado o peca de exceso de confianza?". Los entornos aislados de ejecución para agentes son la solución de ingeniería: entornos con un alcance muy limitado donde los agentes pueden leer y escribir código, ejecutar shells, iniciar servidores o abrir navegadores, mientras usted controla estrictamente los sistemas de archivos, la red, las credenciales y el ciclo de vida. En lugar de confiar en el modelo, limita el alcance de los riesgos.

Por qué los agentes de codificación necesitan un entorno de ejecución aislado dedicado

Los agentes de codificación modernos, como Claude Code, LangChain Deep Agents, los entornos de codificación de Docker y herramientas similares, ya no se comportan como simples chatbots con acceso a archivos. Pueden leer repositorios completos, editar archivos, ejecutar comandos de shell, manipular Git, iniciar compilaciones de Docker, comunicarse con API externas e incluso operar entornos de escritorio completos a través de un navegador. La documentación del proveedor es muy explícita al respecto: Claude Code se presenta como un asistente de desarrollo ágil que puede inspeccionar el código fuente, editarlo y ejecutar comandos; los agentes profundos de LangChain utilizan un entorno aislado como el lugar donde ejecutan comandos de shell, administran sistemas de archivos y delegan tareas a subagentes para garantizar el aislamiento.

Este conjunto de capacidades es precisamente lo que hace que estos agentes sean útiles, y a la vez, arriesgados desde el punto de vista operativo. Una vez que un modelo pueda ejecutarse pytestInstalar paquetes npm, abrir ramas o depurar fallos de compilación: basta con unas pocas llamadas a herramientas para modificar scripts de despliegue, subir imágenes defectuosas, ajustar configuraciones de CI o extraer tokens mediante solicitudes HTTP. Tanto la guía de seguridad de agentes de OpenAI como el trabajo del NIST sobre el secuestro de agentes hacen hincapié en la inyección de mensajes: instrucciones maliciosas ocultas en archivos, páginas web o registros pueden dirigir silenciosamente a un agente hacia acciones que nunca se pretendió autorizar.

Muchos equipos comienzan con flujos de trabajo ingenuos que requieren "solicitar aprobación" para cada comando, y rápidamente descubren que no son escalables. Anthropic ha compartido públicamente que los usuarios aprobaron el 93% de las solicitudes de permisos de Claude Code; el entorno aislado Claude de Docker incluso inicia Claude Code con --skip-permissions Por defecto, se prioriza el aislamiento en tiempo de ejecución en lugar de una avalancha de diálogos. Los usuarios experimentan fatiga por la necesidad de aprobación, especialmente al ejecutar varios agentes en paralelo y cambiar de contexto entre múltiples solicitudes. En ese punto, los diálogos de confirmación se convierten en un mero trámite, no en un control fiable.

Un entorno de ejecución aislado (sandbox) cambia el modelo de seguridad de "confiar en que el usuario lea todas las indicaciones" a "asumir que algunos comandos serán erróneos o maliciosos, y limitar el daño que puedan causar". El entorno aislado se convierte en el límite estricto que delimita qué archivos, procesos, redes y secretos puede tocar el agente, incluso cuando está siendo manipulado mediante inyección directa o simplemente cometiendo errores.

También existe un argumento básico sobre la experiencia del desarrollador: los agentes necesitan suficiente espacio para poder trabajar eficazmente. Si se aplican restricciones excesivas y poco rigurosas, comandos sencillos como compilaciones o pruebas fallan constantemente debido a errores de permisos difíciles de detectar. Los mejores sistemas, como los implementados por Cursor en macOS/Linux/Windows o por Cloudflare, Heroku y Google Cloud para cargas de trabajo alojadas, buscan brindar a los agentes una experiencia similar a la de una computadora real dentro de un entorno controlado.

Lo que realmente aísla un entorno de ejecución aislado para agentes

Un entorno aislado adecuado para agentes no es simplemente "otro lugar donde ejecutar código", sino un conjunto de límites explícitos que definen el radio de acción. Se pueden identificar cinco limitaciones principales que se repiten una y otra vez en plataformas líderes como Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B o Daytona.

En primer lugar, el límite del sistema de archivos: el agente solo debe ver el espacio de trabajo que usted comparte intencionadamente. La documentación de LangChain describe el entorno aislado como la barrera que mantiene a los agentes alejados de los archivos del host; el modelo de entorno aislado de Docker deja muy claro que la microVM solo ve un directorio de proyecto montado explícitamente. Todo lo que esté fuera de ese árbol es invisible o de solo lectura, por lo que el agente no puede leerlo libremente. ~/.ssh o reescribir las configuraciones del sistema.

En segundo lugar, el límite entre el proceso y el núcleo: las cargas de trabajo de los agentes no deben compartir un núcleo del host sin procesar ni una tabla de procesos. La arquitectura de entorno aislado de Docker aísla cada entorno en su propio entorno. microVM y kernel de LinuxFirecracker (utilizado internamente por varios proveedores) trata el límite de la máquina virtual como la primera capa de aislamiento, y luego agrega seccomp, espacios de nombres, cgroups y restricciones tipo jaula. El GKE Agent Sandbox de Google logra un efecto similar dentro de Kubernetes usando gVisor: una capa de "centinela" intercepta las llamadas al sistema y media el acceso al nodo subyacente.

En tercer lugar, el límite de la red: sin una política de red, un agente aislado sigue siendo una máquina de exfiltración de datos. La mayoría de las plataformas serias ahora incluyen de forma predeterminada la opción de "denegar todo el tráfico saliente". Docker Sandboxes, por ejemplo, bloquea HTTP/HTTPS hasta que se permita explícitamente, interrumpe el tráfico TCP/UDP/ICMP sin procesar y no permite el tráfico a rangos de IP privadas ni a localhost a menos que se configuren excepciones. Cloudflare, Google y otras empresas diseñan sus sandboxes para que las llamadas salientes pasen por proxies programables donde se puede inyectar autenticación, filtrar destinos y auditar el uso.

En cuarto lugar, el límite de las credenciales: la exposición de información confidencial sin procesar dentro del entorno aislado debe considerarse como último recurso, no como la opción predeterminada. El diseño de Docker enruta las llamadas HTTP a través de un proxy del lado del host que puede adjuntar tokens o claves API a las solicitudes sin colocar esos valores directamente dentro de la máquina virtual. De manera similar, los entornos aislados de Cloudflare inyectan credenciales en la capa de red, no mediante variables de entorno. De este modo, incluso si la inyección de comandos convence al agente de "imprimir todas las variables de entorno", no hay nada valioso que robar.

En quinto lugar, el límite del ciclo de vida: los espacios de trabajo de los agentes rara vez existen para un solo comando; necesitan una semántica explícita para iniciar, pausar, crear instantáneas, bifurcar y finalizar. E2B expone sistemas de archivos aislados, comandos en segundo plano y volúmenes que pueden persistir más allá del ciclo de vida de un único entorno aislado. Freestyle se centra en el arranque, la suspensión y la reanudación ultrarrápidos de máquinas virtuales mediante la creación de instantáneas y la ramificación del estado en memoria. Daytona añade entornos aislados basados ​​en instantáneas, además de políticas de detención, archivado y eliminación automáticos, lo que permite mantener algunos entornos durante un largo periodo y tratar otros como desechables.

Una vez que comprenda estos cinco ejes (sistema de archivos, proceso, red, credenciales y ciclo de vida), podrá interpretar la página de cualquier producto de entorno aislado como una serie de ventajas y desventajas. Un contenedor con kernel compartido, un montaje de host grande pero reglas de salida estrictas es muy diferente de una microVM sin montajes de host pero con una red más permisiva. Para los agentes de programación que necesitan instalar dependencias, ejecutar navegadores o crear imágenes Docker, los límites más estrictos propios de las máquinas virtuales suelen ser la opción predeterminada más segura.

Aislamiento de procesos en macOS, Linux y Windows para agentes de codificación locales

En los portátiles de los desarrolladores, no siempre es posible crear entornos aislados de microVM de alto rendimiento, por lo que los equipos han tenido que ser creativos con el aislamiento nativo del sistema operativo. El trabajo reciente de Cursor en entornos aislados locales es un buen ejemplo de cómo adaptarlo a las particularidades de macOS, Linux y Windows, manteniendo al mismo tiempo una API unificada para la capa de agente.

En macOS, se evaluaron varias opciones: App Sandbox, contenedores genéricos, máquinas virtuales completas y una tecnología de larga duración pero "obsoleta" llamada Seatbelt. App Sandbox habría requerido firmar cada binario que un agente pudiera ejecutar, lo que aumentaría drásticamente la complejidad e incluso otorgaría confianza transitiva a los binarios generados. Los contenedores Linux habrían obligado a los usuarios de macOS a usar binarios exclusivos de Linux, y las máquinas virtuales completas presentaban una latencia de arranque y una sobrecarga de memoria inaceptables para los flujos de codificación interactivos.

Cinturón de seguridad, al que se accede a través de sandbox-exec, a pesar de su antigüedad, terminó siendo la opción más pragmática. Permite ejecutar un comando bajo un perfil de entorno aislado que restringe todo el árbol de procesos con un lenguaje de políticas detallado: se pueden incluir en la lista blanca o bloquear llamadas al sistema específicas y limitar los permisos de lectura/escritura a archivos o directorios específicos. Cursor genera estas políticas dinámicamente en tiempo de ejecución en función de la configuración del espacio de trabajo y del administrador, además de la del usuario. .cursorignore, por lo que los caminos ignorados quedan fuera de los límites dentro del entorno aislado.

En Linux, el núcleo expone las primitivas adecuadas (seccomp para el filtrado de llamadas al sistema y Landlock para las restricciones del sistema de archivos), pero deja la composición en manos del espacio de usuario. En lugar de depender de los wrappers de OSS existentes que no admitían ignorados específicos del repositorio como .cursorignoreCursor optó por orquestar Landlock y seccomp directamente. Seccomp prohíbe las llamadas al sistema peligrosas; Landlock impone reglas de lectura/escritura basadas en rutas, incluso permitiendo que se superpongan a los espacios de trabajo del usuario, de modo que los archivos ignorados sean completamente inaccesibles o se reemplacen por copias protegidas que los procesos aislados no pueden leer ni modificar.

Una particularidad de Linux reside en el rendimiento: volver a montar o reescribir todos los archivos ignorados es la parte más lenta de la configuración del entorno aislado. El filtrado diferido al estilo macOS, que permite ver la ruta exacta del archivo en el momento de la llamada al sistema, simplificaría esto, pero seccomp-bpf de Linux no facilita esa inspección de rutas, por lo que existe una verdadera disyuntiva de ingeniería entre un aislamiento estricto y la velocidad de inicio.

En Windows, crear un entorno aislado nativo verdaderamente equivalente sigue siendo más difícil porque la mayoría de las primitivas de aislamiento están optimizadas para navegadores y no para herramientas de desarrollo de propósito general. Cursor actualmente ejecuta un entorno aislado de Linux dentro de WSL2 para usuarios de Windows, aprovechando el aislamiento de Linux hasta que estén disponibles funcionalidades más avanzadas. Están colaborando con Microsoft para exponer las capacidades necesarias para que, con el tiempo, los agentes de Windows puedan disfrutar de un entorno aislado nativo de primera clase sin depender de WSL.

El denominador común de estos enfoques específicos del sistema operativo es una API de entorno aislado unificada. Desde el punto de vista del agente, se trata simplemente de una "herramienta básica" con capacidades y reglas definidas. Internamente, Seatbelt, Landlock/seccomp o el aislamiento basado en WSL2 aplican esas reglas de manera diferente según la plataforma.

Enseñar a los agentes a comprender y respetar el entorno de pruebas.

Un entorno aislado (sandbox) solo resulta útil si el agente puede anticipar qué funcionará dentro de él y cuándo necesita elevar sus privilegios o salir del entorno. Eso suena obvio, pero en la práctica requirió una iteración sorprendentemente profunda en el diseño de las herramientas y las indicaciones para los proveedores que distribuyen agentes de codificación.

El primer paso que dieron muchos equipos fue mejorar las descripciones de las herramientas, especialmente para la ejecución desde la línea de comandos. En lugar de una herramienta genérica como «ejecutar comando de shell», la descripción especifica claramente qué recursos son accesibles: si el comando tiene acceso al sistema de archivos, a Git, a la red o a un entorno completamente sin conexión, según la configuración del usuario. También documenta cómo el agente puede solicitar permisos elevados (por ejemplo, para acceder a internet) cuando sea necesario. Este trabajo de ingeniería de impulsos suele ser muy empírico: los equipos ejecutan flujos de implementación comunes, observan dónde el modelo predice erróneamente las capacidades, ajustan las descripciones de las herramientas y repiten el proceso.

Posteriormente, se utilizan pruebas de rendimiento internas como "Cursor Bench" o conjuntos de evaluaciones similares para comparar el rendimiento de los agentes con y sin el uso de entornos aislados (sandboxing). Un modo de fallo inicial era muy recurrente: el agente reintentaba ciegamente el mismo comando de terminal que había fallado una y otra vez, en lugar de darse cuenta de que estaba chocando con una restricción del entorno aislado. Sin una señal clara sobre el motivo del fallo del comando, el modelo no podía aprender el patrón.

La solución consistió en mostrar explícitamente los errores del entorno aislado en los resultados de la herramienta, a menudo con una sugerencia sobre qué hacer a continuación. Cuando un comando se bloqueaba debido a una regla del sistema de archivos o de la red, la herramienta de línea de comandos incluía una breve explicación como «bloqueado por el entorno aislado: el acceso a la red saliente está deshabilitado para esta sesión» y, en algunos casos, una sugerencia de que el agente podía solicitar permisos elevados. Tras este cambio, los agentes se volvieron mucho más resistentes: dejaron de ejecutar comandos sin solución y, o bien ajustaron su plan, o bien solicitaron la capacidad necesaria.

Las evaluaciones presenciales son útiles, pero solo cuentan una parte de la historia. Para determinar si el uso de entornos aislados (sandboxing) perjudica la experiencia del usuario, los equipos han implementado gradualmente esta funcionalidad en entornos de producción, analizando las tasas de error, los tiempos de finalización y los canales de retroalimentación. En la práctica, los proveedores informan que una fracción considerable de las consultas en plataformas compatibles ahora se ejecutan completamente dentro de entornos aislados (con clientes empresariales como NVIDIA entre los primeros en adoptarlos) y que los agentes en entornos aislados se detienen para obtener aprobación aproximadamente un 40 % menos en flujos de trabajo reales, lo que ahorra horas de revisión manual y reduce el riesgo.

De cara al futuro, existe un gran interés en los "agentes nativos de entorno aislado": modelos entrenados directamente en función de las limitaciones de su entorno. En lugar de tratar la consola, el navegador o el sistema de archivos como herramientas abstractas, estos agentes comprenderían que operan en un entorno de ejecución con un alcance limitado, pueden escribir scripts y programas de larga duración y deben respetar condiciones de límite como "sin acceso a la red" o "el espacio de trabajo es de solo lectura". Este entrenamiento podría mejorar considerablemente su capacidad para planificar secuencias de acciones seguras y eficientes, evitando así chocar contra barreras invisibles.

Entornos de prueba en la nube: Cloudflare, Google Cloud, Heroku y otros.

Fuera del entorno del desarrollador, una gran oleada de proveedores de infraestructura compite por ofrecer entornos de pruebas alojados y optimizados específicamente para agentes de IA. Sus objetivos son los mismos (aislamiento, control y rendimiento), pero las ventajas y desventajas son algo diferentes a escala de la nube.

Cloudflare Sandboxes, que se basa en Cloudflare Containers y ya está disponible para el público en general, pretende tener la apariencia y el funcionamiento de entornos de desarrollo completos para agentes. Cada entorno aislado es un espacio de trabajo persistente y aislado al que se accede por su nombre. Si está inactivo, se inicia bajo demanda; si está inactivo, se suspende automáticamente para ahorrar recursos computacionales y se reanuda con la siguiente solicitud. Los desarrolladores (o agentes) pueden interactuar con él mediante métodos tipados como exec, gitCheckout, writeFiley más, utilizando un SDK de JavaScript/TypeScript.

Uno de los problemas más complejos de la computación en la nube es la autenticación segura desde dentro de los entornos aislados de los agentes. Los agentes suelen necesitar acceder a servicios privados, pero no conviene tener credenciales sin procesar almacenadas en variables de entorno. Cloudflare inyecta las credenciales en la capa de proxy de red, asignando las solicitudes salientes por host a una lógica personalizada que adjunta tokens desde un almacenamiento seguro. El proceso aislado nunca ve los secretos reales, pero la llamada se autentica igualmente. Este diseño admite la inyección dinámica de credenciales con reconocimiento de identidad y se integra perfectamente con las vinculaciones de Workers.

Para flujos de trabajo que requieren un uso intensivo de la terminal, Cloudflare añadió una experiencia completa de PTY (pseudoterminal) conectada mediante WebSockets y xterm.js. Los agentes y los usuarios pueden abrir sesiones de shell en vivo, interrumpir procesos, reconectarse más tarde y reproducir la salida anterior. Cada PTY tiene su propio directorio de trabajo y entorno, y la salida se almacena en búfer en el servidor para que los clientes que se reconectan puedan ponerse al día con los registros perdidos.

Además del acceso directo a la línea de comandos, Cloudflare también ofrece "contextos de ejecución de código" persistentes para lenguajes como Python, JavaScript y TypeScript. A diferencia de muchos ejecutores de fragmentos que ejecutan cada fragmento de forma aislada, estos contextos conservan las variables, las importaciones y el estado entre llamadas, de forma similar a un cuaderno Jupyter. Los agentes pueden cargar datos en una llamada, transformarlos en otra y generar gráficos o tablas HTML sin tener que volver a analizar e importar todo constantemente.

Para las tareas de desarrollo web, los entornos aislados de Cloudflare admiten procesos en segundo plano, comprobaciones de estado y URL de vista previa en tiempo real. Un agente puede comenzar npm run dev Como tarea en segundo plano, supervise los registros hasta que el servidor esté listo y, a continuación, exponga el puerto tras una URL de vista previa pública. Métodos como waitForPort() or waitForLog() permitir que los agentes secuencien acciones basadas en señales de disponibilidad reales en lugar de ingenuas. sleep(2s) suposiciones.

Los flujos de trabajo basados ​​en eventos se ven potenciados por las funciones básicas de monitorización de archivos, respaldadas por el mecanismo inotify de Linux. Un agente puede suscribirse a los cambios en /workspace/src y volver a ejecutar automáticamente las pruebas o compilaciones cuando se modifican los archivos TypeScript. Este es el mismo ciclo de retroalimentación en el que confían los desarrolladores humanos, pero hecho nativo del agente a través de API como sandbox.watch() y flujos de eventos enviados por el servidor.

Para cerrar el ciclo de vida, Cloudflare está implementando instantáneas reales: capturas del estado a nivel de máquina virtual que se pueden restaurar en segundos desde el almacenamiento R2. Las instantáneas conservan el estado del sistema de archivos, la configuración del sistema operativo, las dependencias instaladas y los archivos de datos; las versiones futuras también restaurarán el estado de la memoria en tiempo real para una reanudación instantánea. Los agentes (u orquestadores) pueden activar instantáneas mediante programación para puntos de control o escenarios de ramificación, y luego crear múltiples entornos aislados a partir de la misma instantánea para explorar hipótesis paralelas de forma independiente.

En cuanto a precios, Cloudflare adoptó un modelo de "solo CPU activa": se le factura por los ciclos de CPU realmente utilizados, no por el tiempo de inactividad mientras los agentes esperan a que se completen las tareas LLM. En combinación con los enormes límites de concurrencia para las instancias "lite" y las de mayor tamaño, esto hace factible ejecutar una gran flota de agentes sin malgastar dinero en contenedores inactivos.

Por el contrario, el entorno aislado de agentes GKE de Google Cloud está profundamente integrado con Kubernetes y gVisor. La idea es permitirle ejecutar cargas de trabajo de agentes en pods aislados dentro de sus propios clústeres. Cree un clúster de GKE (Autopilot puede habilitar gVisor automáticamente, mientras que los clústeres estándar necesitan clases de tiempo de ejecución explícitas y grupos de nodos habilitados para gVisor) y luego implemente un controlador Agent Sandbox mediante manifiestos versionados.

Dos recursos personalizados fundamentales impulsan el modelo: SandboxTemplate y SandboxWarmPool. SandboxTemplate actúa como un plano reutilizable que especifica una plantilla de pod (imagen, puertos, recursos, runtimeClassName: gvisor, etc.) para entornos de ejecución aislados, como un entorno Python. SandboxWarmPool Mantiene un número configurado de cápsulas precalentadas listas para su uso casi instantáneo, evitando arranques en frío cuando un agente necesita un entorno fresco en menos de un segundo.

A Sandbox Router El servicio actúa entonces como puerta de enlace para el tráfico entre los clientes y estos pods aislados. En desarrollo, puedes canalizar el tráfico a través de kubectl port-forward sin exponer direcciones IP públicas. En producción, normalmente se configura el enrutador con un ingress y mTLS adecuados. En el lado del cliente, Google proporciona una biblioteca de Python llamada "Agentic Sandbox" que abarca todo el ciclo de vida: crear una solicitud de sandbox a partir de una plantilla, esperar a que esté lista, ejecutar comandos de shell y limpiar cuando termine.

En esencia, todo esto sigue siendo "simplemente Kubernetes", pero empaquetado en una historia coherente para los entornos de ejecución de agentes. gVisor proporciona aislamiento de procesos y llamadas al sistema, SandboxTemplate estandariza las configuraciones, WarmPool resuelve la latencia de inicio y el enrutador junto con el cliente Python lo hacen conveniente para aplicaciones centradas en LLM.

Heroku, por otro lado, se basa en un componente fundamental muy consolidado: los dynos de un solo uso. Durante años, los usuarios de Heroku han ejecutado tareas puntuales (migraciones, scripts de mantenimiento, tareas administrativas) en dynos efímeros que se activan bajo demanda y se eliminan al finalizar. Heroku reutilizó esta infraestructura como entornos aislados de ejecución de código, lanzados junto con sus servicios de Inferencia Gestionada y Agentes. Un agente escribe fragmentos de código en Python, Ruby, Node o Go; Heroku los ejecuta dentro de dynos de corta duración y transmite los resultados, limitando el impacto al contenedor efímero.

Puedes acceder a estos entornos aislados mediante las herramientas integradas en la API de agentes de Heroku o implementando servidores de código abierto Model Context Protocol (MCP). Los servidores MCP exponen puntos finales de herramientas estandarizados, por lo que clientes como Agentforce, Claude Desktop o Cursor pueden tratar el entorno aislado de Heroku como un backend de ejecución de código remoto genérico. Cada servidor admite límites específicos del tiempo de ejecución (como max_calls por bucle de agente) para evitar que los agentes entren en bucles ajustados y costosos.

Los agentes avanzados de LangChain añaden otra dimensión al integrarse con proveedores de entornos aislados de terceros como Runloop, Daytona y Modal. El funcionamiento es sencillo: el Deep Agent sigue ejecutándose donde se desee (localmente o en la nube), pero cuando necesita ejecutar comandos, crear archivos o ejecutar código, estas operaciones se envían a un entorno aislado remoto. Los scripts de configuración pueden precargar variables de entorno, clonar repositorios, instalar herramientas y mucho más, de modo que cada agente dispone de un entorno limpio y controlado. Los gestores de contexto se encargan de la creación y la limpieza, aunque la documentación recomienda encarecidamente monitorizar los paneles del proveedor para detectar cualquier entorno aislado de larga duración que se haya olvidado.

Rendimiento, estado y ramificación: por qué la velocidad es importante para los agentes.

En la práctica, un entorno aislado lento pero ultra seguro será eludido; las herramientas para desarrolladores dependen completamente de la latencia. Los agentes de codificación no se comportan como procesos por lotes nocturnos. Ejecutan bucles interactivos: leen código, proponen ediciones, ejecutan pruebas, analizan registros, utilizan herramientas, esperan a que intervengan los humanos y luego repiten el proceso. En sesiones reales, también exploran múltiples ramificaciones de un problema, abandonan algunas rutas y retoman otras más adelante.

Por eso, plataformas como Freestyle se obsesionan con tiempos de ciclo de vida de máquinas virtuales inferiores a un segundo y una semántica de estado enriquecida. Sus máquinas virtuales son máquinas Linux completas con acceso de administrador, servicios systemd, compatibilidad con virtualización anidada y conectividad de red completa. La documentación indica que el aprovisionamiento se realiza en menos de 800 ms desde la llamada a la API hasta la ejecución de la máquina virtual, la suspensión/reanudación en menos de 100 ms y la capacidad de crear instantáneas o bifurcar máquinas virtuales durante la ejecución con un impacto mínimo en el rendimiento. Mencionan explícitamente el estado del navegador como un factor clave: si un agente ha llevado un navegador a un estado de interés, puede bifurcar esa máquina virtual 20 veces a partir de la misma instantánea en lugar de recrear ese estado desde cero.

La función SandboxWarmPool de Google para GKE expresa la misma idea en términos de Kubernetes: mantener un grupo de pods precalentados para que los agentes no paguen las penalizaciones completas por arranque en frío en cada nueva ejecución. Los espacios de trabajo basados ​​en instantáneas de Daytona, junto con las políticas de detención, archivo y eliminación automáticas, ajustan el ciclo de vida para diferentes tipos de sesiones: entornos de desarrollo activos, experimentos efímeros y líneas base de larga duración.

El énfasis que E2B pone en los procesos en segundo plano, los directorios monitorizables, los sistemas de archivos aislados y los volúmenes reutilizables es otra cara de la misma moneda. Estas funciones permiten que un agente mantenga en funcionamiento un servidor de desarrollo o un entorno de pruebas mientras explora los cambios en el código, o que comparta un volumen persistente entre varios entornos aislados efímeros a lo largo del tiempo. Sin esto, los agentes terminan ejecutando comandos puntuales y perdiendo el contexto, lo que reduce drásticamente la productividad.

Una forma útil de evaluar cualquier entorno de pruebas para el trabajo con agentes es hacer algunas preguntas directas. ¿Puedo crear un entorno nuevo en menos de un segundo? ¿Puedo guardar y restaurar el estado de forma limpia, incluyendo compilaciones parciales o sesiones del navegador? ¿Puedo bifurcar el estado para explorar en paralelo? ¿Puedo mantener espacios de trabajo duraderos pero eficientes en recursos para flujos de trabajo que se pueden retomar más tarde? Cuantas más respuestas afirmativas obtenga, más podrán sus agentes comportarse como ingenieros reales en lugar de simples ejecutores de scripts sin estado.

Secretos, política de red y confianza en el espacio de trabajo como plano de control real

Incluso con un aislamiento perfecto del host, es fácil crear un sistema inseguro si se ignoran los secretos, la política de red y la confianza en el espacio de trabajo. La documentación de Docker sobre entornos aislados es sorprendentemente clara al respecto. La microVM y su demonio Docker privado conforman el límite de confianza principal con el host. Sin embargo, dentro de la VM, el agente tiene control total a nivel de administrador, y el espacio de trabajo compartido se monta con permisos de lectura y escritura. Por defecto, cualquier modificación de archivos se refleja inmediatamente en el host. El acceso a la red está denegado por defecto y solo se permite mediante reglas explícitas. Las solicitudes HTTP utilizan un proxy del lado del host que puede inyectar credenciales sin exponer información confidencial a la VM.

Esto significa que aislar el host es solo el primer paso; aún hay que pensar en lo que el agente puede hacer al espacio de trabajo y al mundo exterior. La documentación de Docker advierte explícitamente que si un agente edita scripts que los humanos ejecutan posteriormente (ganchos de Git, configuraciones de CI, definiciones de tareas de IDE, Makefile objetivos, package.json scripts: el daño puede “rebotar” de vuelta al host o a los sistemas CI cuando se ejecutan esos scripts. Incluso destacan que Git se engancha en .git/ no aparezcan en git diff, lo que facilita la persistencia silenciosa de la lógica maliciosa.

El uso de credenciales mediante proxy es potente pero sutil. El proxy de salida de Docker garantiza que los secretos permanezcan fuera de la máquina virtual, pero aún así permite que el agente actúe utilizando esas identidades contra los hosts permitidos. Algunos flujos, como escribir variables de entorno personalizadas en archivos como /etc/sandbox-persistent.sh – Rompe esta barrera almacenando intencionadamente secretos dentro de la máquina virtual, lo cual solo es seguro si confías genuinamente en el agente y en el entorno aislado.

El ámbito de la configuración es tan importante como los secretos. Las preguntas frecuentes de Docker señalan que las configuraciones a nivel de usuario como ~/.claude or ~/.codex En el host, la configuración no se copia en el entorno aislado; solo la configuración del proyecto en el espacio de trabajo compartido es visible. La documentación de configuración de Anthropic recalca que la configuración a nivel de proyecto (herramientas, permisos, servidores MCP, ganchos) anula la configuración a nivel de usuario y se comparte entre equipos. En otras palabras, las políticas, instrucciones y complementos que se adjuntan al repositorio se convierten en la interfaz principal que ve el agente.

La guía de habilidades de OpenAI recalca puntos similares con un vocabulario ligeramente diferente. Las Skills (paquetes de herramientas) pueden introducir riesgos de exfiltración de datos mediante inyección de mensajes. La documentación advierte sobre el peligro de exponer un mercado de Skills público y sin supervisión directamente a los usuarios finales, ya que los archivos SKILL.md maliciosos pueden anular políticas, desencadenar acciones destructivas o filtrar datos privados. Recomiendan revisar las Skills de los desarrolladores, limitarlas a flujos de trabajo específicos, ocultar las acciones de alto impacto tras aprobaciones adicionales y comprobaciones de políticas, y tratar las Skills como parte del modelo de amenazas.

Al unir las piezas, el plano de control "real" para los entornos de agentes abarca cuatro capas. El aislamiento del host protege sus máquinas y nodos del clúster. La confianza en el espacio de trabajo protege al futuro usuario o CI que ejecutará archivos generados dentro del entorno aislado. La política de red protege los sistemas externos y las fuentes de datos privadas. La gestión de credenciales protege las identidades a través de las cuales el agente puede actuar. Un diseño robusto ofrece soluciones para las cuatro necesidades, no solo para la primera.

Además, sigue siendo necesario mantener un sano escepticismo respecto a la inyección rápida y el secuestro de agentes. NIST, OWASP y OpenAI describen variantes del mismo patrón: la entrada no confiable (un archivo README, una página web, un archivo de registro) contiene instrucciones maliciosas que redirigen el comportamiento del agente. La generación mejorada con recuperación y el ajuste fino no solucionan esto mágicamente. Un entorno aislado bien instrumentado, junto con una buena política, no puede evitar que el modelo sea engañado, pero sí puede reducir drásticamente las consecuencias negativas cuando esto sucede.

Las plataformas en la nube y los entornos de ejecución de agentes están empezando a incorporar estas lecciones. Los proxies secretos, los dominios de salida permitidos, las configuraciones con ámbito de repositorio, los subagentes con capacidades más limitadas, los flujos de aprobación basados ​​en hooks y los entornos aislados reproducibles son todas piezas del mismo rompecabezas: aceptar que los modelos son falibles y diseñar el entorno de manera que el coste de esa falibilidad se mantenga acotado.

Tanto en entornos locales como en la nube, un entorno de ejecución aislado para agentes se puede concebir mejor como una línea cuidadosamente trazada: no hace que el modelo sea más inteligente, sino que hace que sus errores sean menos catastróficos y más observables. Con la combinación adecuada de controles de sistema de archivos, procesos, red, secretos y ciclo de vida, además de una enseñanza inteligente al agente sobre su entorno, puede permitir que los sistemas de IA clonen repositorios, ejecuten pruebas, inicien navegadores e incluso interactúen con sistemas similares a los de producción, sin darles las claves de todo lo que le importa.

Esto significa que aislar el host es solo el primer paso; aún hay que pensar en lo que el agente puede hacer al espacio de trabajo y al mundo exterior, incluidos los riesgos como ejecución remota de código. La documentación de Docker advierte explícitamente que si un agente edita scripts que los humanos ejecutan posteriormente (ganchos de Git, configuraciones de CI, definiciones de tareas de IDE, Makefile objetivos, package.json scripts: el daño puede "rebotar" de vuelta al host o a los sistemas de CI cuando se ejecutan esos scripts.