Un agente que escribe código y no puede ejecutarlo sirve de poco: la mitad del valor está en el ciclo de probar, ver el error y corregir. Por eso casi todos los equipos terminan dándole al modelo alguna forma de ejecución, y la primera versión suele ser la más peligrosa: un intérprete corriendo en la misma máquina del desarrollador o del servidor de la aplicación, con el usuario que lanzó el proceso y todo lo que ese usuario alcanza.
La pregunta correcta no es si conviene aislar, sino cuánto. El aislamiento tiene costo en latencia, en complejidad operativa y en capacidad del agente para hacer su trabajo. Vale la pena decidir ese punto de forma explícita y no descubrirlo el día en que un script generado borre un directorio que no debía tocar.
Los cuatro ejes del aislamiento
Proceso
Es la frontera básica: qué puede tocar el código en la máquina donde corre. Como mínimo, ejecución bajo un usuario dedicado sin privilegios, sin capacidad de escalar, con límites de memoria y CPU y con un tiempo máximo de ejecución. Los límites de recurso no son solo una medida de eficiencia: un bucle infinito o una bomba de memoria son la forma más frecuente de incidente en estos entornos, muy por delante de cualquier ataque deliberado.
Red
Es el eje que más se descuida y el que más consecuencias tiene. Con salida a internet abierta, el sandbox deja de ser un sandbox: cualquier dato que el proceso alcance puede salir, y cualquier cosa puede entrar. La postura razonable es denegar por defecto y habilitar destinos concretos —el índice de paquetes, la API interna que el agente necesita— a través de un proxy que registre lo que pasa. Si tu agente necesita instalar dependencias, esa lista debería apuntar a un repositorio propio y no al registro público directo.
Sistema de archivos
El código generado debería ver un árbol montado para esa ejecución y nada más: el directorio de trabajo con lo que necesita, escritura solo ahí, y el resto del sistema en solo lectura o simplemente ausente. Conviene revisar qué se monta por comodidad: la carpeta del usuario completa, el directorio de configuración con los perfiles de nube o el socket del demonio de contenedores anulan el aislamiento entero por sí solos.
Secretos
Un agente que escribe código suele necesitar credenciales para probarlo. El error habitual es exponerlas como variables de entorno del proceso: quedan legibles para cualquier línea que el modelo escriba, y de ahí pasan a los logs, a las trazas y a la memoria del agente. La alternativa es que el sandbox no tenga secretos y que las llamadas autenticadas salgan por un intermediario que inyecta la credencial fuera del alcance del código, con permisos acotados y vida corta, siguiendo el mismo criterio que aplicamos al modelo de permisos de agentes.
Un sandbox con salida de red abierta y credenciales en el entorno no es un sandbox: es un directorio distinto.
Los niveles, y qué se gana o se pierde en cada uno
No existe una única respuesta correcta. Existe una escala, y cada peldaño intercambia capacidad por contención.
- Mismo proceso. El código se ejecuta dentro de la aplicación que hospeda al agente. Latencia nula y cero fricción; ninguna contención real. Solo es defendible para evaluar expresiones en un lenguaje restringido, sin acceso a sistema ni a red, y aun así conviene desconfiar: los intérpretes restringidos tienen un historial largo de fugas.
- Subproceso con usuario dedicado. Barato de implementar y suficiente para contener accidentes: bucles, escrituras torpes, dependencias que se instalan donde no deben. No contiene a un atacante que controle lo que se escribe, porque comparte núcleo, red y, con frecuencia, más sistema de archivos del que se cree.
- Contenedor. El punto de equilibrio habitual. Da espacios de nombres separados, control de recursos, imagen reproducible y política de red por contenedor, a cambio de operar una capa más. El límite conocido es que el núcleo sigue siendo compartido, así que la configuración importa tanto como la tecnología: sin privilegios, sin montar el socket del demonio, con perfil de seccomp y sistema de archivos raíz en solo lectura.
- MicroVM o entorno efímero remoto. Aislamiento con núcleo propio y destrucción tras cada ejecución. Es lo apropiado cuando el código proviene de terceros o cuando varios clientes comparten infraestructura. El costo es de arranque, de complejidad y de que el agente pierde continuidad entre ejecuciones, lo que obliga a diseñar cómo viaja el estado.
El mínimo razonable
Para uso interno, con código que el agente genera a partir de peticiones de empleados autenticados, el piso que recomendamos es un contenedor sin privilegios, con red denegada por defecto y salida por proxy hacia una lista corta, sistema de archivos acotado al directorio de trabajo, sin secretos en el entorno, con límites de CPU, memoria y tiempo, y destrucción del entorno al terminar. Todo eso es configuración, no desarrollo, y suele instalarse en días.
Falta una pieza que no es aislamiento pero se paga igual de cara si no está: registro. Qué código se ejecutó, con qué entrada, qué escribió, a dónde intentó conectarse y qué devolvió. Sin ese rastro, cuando algo salga raro no vas a poder responder si fue un error del modelo o una instrucción ajena, y la respuesta al incidente se convierte en arqueología.
Conviene también tener claro qué no resuelve el sandbox. Contiene la ejecución, no la decisión. Si el agente puede llamar a una herramienta autorizada que envía correo o modifica un registro, esa acción ocurre fuera de la caja y con permisos legítimos. El aislamiento protege la máquina; los permisos protegen el negocio. Hacen falta los dos, y el orden en que se implementan importa menos que el hecho de no confundir uno con el otro.