Experimentos revelan limitaciones críticas en la ejecución autónoma de agentes de código
21 de octubre de 2026 · 3 min de lectura
Un desarrollador que utiliza herramientas de inteligencia artificial para la creación de software descubrió que la delegación completa de proyectos a sistemas autónomos enfrenta barreras técnicas significativas relacionadas con la seguridad, la gestión de recursos y la recuperación ante fallos. El objetivo inicial era permitir que un agente de código, como Codex CLI o Claude Code, gestionara el ciclo de vida completo de un producto a partir de una descripción en lenguaje natural, sin intervención manual constante en cada sesión. Sin embargo, la transición de un esquema teórico a garantías verificables expuso deficiencias en la arquitectura de aislamiento y control de procesos que obligaron a replantear las decisiones iniciales del proyecto.
La primera fase de pruebas se centró en la protección de datos mediante el aislamiento de ejecución en macOS. Aunque el mecanismo de App Sandbox impidió la lectura directa de archivos protegidos, la concesión de acceso a la red permitió al proceso obtener información sensible a través de una interfaz HTTP de prueba. Este hallazgo demostró que bloquear un único canal de acceso no es suficiente si existen rutas alternativas de red. Además, se identificó un fallo en la terminación de procesos: un proceso hijo logró separarse de su grupo padre mediante la función setsid y continuó operando incluso después de que el coordinador considerara la tarea finalizada. En total, se registraron 97 observaciones, de las cuales 40 fueron operaciones permitidas y 57 fueron rechazadas, concluyendo que la arquitectura no cumplía con los requisitos de seguridad obligatorios.
Para abordar estas limitaciones, se implementó una solución basada en máquinas virtuales de Linux aisladas en un equipo Mac. Se configuraron tres entornos virtuales: uno para la ejecución de tareas del agente, otro para el producto en desarrollo y un tercero para verificaciones de confianza. Este diseño eliminó el acceso directo a la red y a los directorios compartidos del sistema anfitrión, canalizando las operaciones a través de un intermediario que validaba el tipo, contexto y permisos de cada acción. Los agentes de código ejecutaron correctamente los escenarios con herramientas y protocolos MCP a través de un proveedor sintético. No obstante, persistió el problema de que el código JavaScript generado por el servidor aislado se ejecutaba en el navegador del usuario en el sistema anfitrión, lo que impedía considerar el producto completamente aislado. La arquitectura con intermediario se mantuvo como candidata viable, aunque el acceso seguro al producto y el intermediario de red completo quedaron pendientes de resolución.
La gestión de recursos presentó otro desafío complejo. Se determinó que asignar 2 GB de memoria a una máquina virtual no garantiza que la carga total en el sistema anfitrión no supere esa cifra, debido a la memoria del proceso de virtualización y otros componentes auxiliares. Un experimento con QEMU/HVF mostró que, aunque 37 de 38 pruebas individuales obtuvieron un resultado positivo, la garantía global para el sistema anfitrión no pudo demostrarse. Las limitaciones del espacio de direcciones virtual no probaban el límite de memoria física, y el control del tiempo de CPU no aseguraba el comportamiento correcto de inicio y parada. Un mecanismo de vigilancia independiente podía detectar excesos, pero operaba de forma reactiva con retrasos. En consecuencia, se separaron los requisitos técnicos de la máquina virtual de la observación del estado del sistema anfitrión, abandonando la pretensión de establecer un límite rígido absoluto para el consumo total de recursos del equipo.