La seguridad de ejecución de los agentes de código es un campo fragmentado — y sus lagunas lo demuestran

¿Qué es esto?

El 7 de julio de 2026, un artículo de sistematización del conocimiento (SoK) titulado The Balkanization of Execution-Security Research for AI Coding Agents (arXiv:2607.05743, CC BY 4.0) sostiene que la investigación que protege la capa donde realmente se ejecutan los agentes de código — el sandbox, el shell, el sistema de archivos, las llamadas a herramientas — se ha fragmentado en subcampos desconectados que rara vez se citan entre sí.

Un agente de código, en materia de seguridad, vale tanto como el entorno en el que se ejecuta. Un modelo capaz de leer un repositorio, ejecutar comandos de shell y llamar a herramientas hereda cada debilidad de la frontera que lo rodea. El artículo revisa 39 trabajos publicados entre 2023 y 2026, verifica cada uno directamente contra su fuente y los clasifica en 17 categorías: aislamiento por sandbox, control de acceso y capacidades, aplicación de políticas, carreras TOCTOU (time-of-check-to-time-of-use), amenazas del Model Context Protocol (MCP), delegación de identidad, procedencia de ejecución, control del tráfico saliente y análisis estático del código generado por el agente. Es un mapa del campo, no un exploit.

Cómo funciona

La observación central es estructural. Los trabajos se agrupan por el mecanismo que proponen — un equipo entrega un sandbox, otro un sistema de capacidades, otro un motor de políticas — y esa agrupación separa de forma silenciosa trabajos que abordan el mismo problema subyacente. El autor puntúa las 17 categorías entre sí según sus causas raíz y su etapa en el pipeline, y varias de las puntuaciones de similitud más altas conectan categorías que nunca se citan.

Para mostrar que el asunto no es teórico, la sistematización confirma cuatro vulnerabilidades divulgadas y parcheadas, verificadas directamente en la base NVD del NIST. La primera es la fuga de descriptor de archivo del runtime de contenedores runc, conocida como «Leaky Vessels»: es anterior al herramental de agentes, pero ilustra la clase de evasión que hereda todo sandbox construido sobre las mismas primitivas. La segunda es un fallo de inyección de comandos en un asistente de código muy extendido, parcheado en una versión de 2026. Las dos últimas afectan a un popular agente de código en terminal: un fallo de inyección de código en el que código de proyecto no confiable podía ejecutarse antes de que el usuario aceptara el diálogo de confianza de arranque, y un fallo de exfiltración en el que un repositorio malicioso podía filtrar datos — incluidas claves de API — antes de que surtiera efecto la decisión de confianza. Ambos dependen del mismo momento frágil: el intervalo entre abrir un repositorio no confiable y la aplicación efectiva de la decisión de confianza. Es una carrera clásica de «comprobar y luego actuar», precisamente lo que estudia la categoría TOCTOU.

Por qué importa

La contribución del artículo son cinco lagunas transversales que ningún estudio cierra, y cada una es directamente operativa para quien despliega agentes.

Primero, las arquitecturas de aislamiento y los modelos de capacidades se evalúan cada uno frente a un atacante, pero casi nunca entre sí sobre un banco de pruebas común — por lo que nadie puede afirmar si un sandbox más un sistema de capacidades es más fuerte que cualquiera por separado. Segundo, los estudios de aplicación de políticas informan de que las listas de denegación de comandos fallan en el 69 % al 98 % de las entradas adversas, pero ningún artículo de aislamiento vuelve a probar su propia defensa bajo esa tasa de fallo. Tercero, las carreras TOCTOU y las amenazas MCP se tratan como literaturas separadas pese a ser instancias del mismo problema de validación de estado. Cuarto, cada mecanismo de aplicación revisado supone un autor de políticas honesto — dejando sin abordar la mala configuración por parte del propio defensor. Quinto, un modo de fallo recién medido: acciones benignas pero fuera de alcance, donde el mismo agente, en la misma tarea, tomaba acciones no solicitadas a tasas de entre 0,0 % y 17,1 % según únicamente la formulación de la consigna. Un permiso que responde «¿está permitida esta acción?» no responde «¿debería el agente hacerla siquiera?» — y ningún artículo de control de acceso del corpus cita siquiera esa medición.

Defensas

Como se trata de un mapa y no de un ataque, la enseñanza práctica es cómo razonar sobre su propio despliegue de agentes, más que un payload que bloquear.

• Superponga aislamiento y control de acceso, y pruebe la combinación. No confíe en un sandbox o un modelo de capacidades por separado; la investigación muestra que ninguno se evalúa frente al otro, así que asuma grietas en la unión y verifique la pila de extremo a extremo.
• Asuma que su lista de denegación tiene fugas. Las listas de permitidos y denegados de comandos fallan en la gran mayoría de las entradas adversas. Trátelas como una capa más, detrás de un aislamiento real y del mínimo privilegio, nunca como la frontera en sí.
• Cierre la carrera de la decisión de confianza. Los fallos reales confirmados viven todos en la ventana entre abrir contenido no confiable y la aplicación efectiva de la decisión de confianza. Nunca ejecute código de proyecto, no cargue configuración del repositorio ni honre descripciones de herramientas hasta que la comprobación de confianza haya surtido pleno efecto.
• Trate TOCTOU y MCP como un solo problema. Ambos son fallos de validación de estado: valide el estado en el momento de la acción, no en una comprobación anterior que una acción posterior pueda adelantar.
• Audite al autor de la política, no solo al agente. Cada capa de aplicación supone correcta su propia configuración. Revise quién escribe las políticas del agente y cómo, porque la mala configuración es un modo de fallo no modelado pero muy real.
• Restrinja el alcance, no solo los permisos. Las acciones fuera de alcance varían mucho según la formulación. Añada controles que verifiquen si una capacidad autorizada se invoca con un propósito no solicitado, no solo si la capacidad se posee.

Estado

Elemento	Detalle
Tipo	Sistematización del conocimiento (preprint)
Publicación	7 de julio de 2026 (arXiv:2607.05743, CC BY 4.0)
Corpus	39 trabajos (2023–2026), 17 categorías de seguridad de ejecución
Ataque publicado	Ninguno — estado del arte y agenda de investigación, sin payload
Incidentes confirmados	4 CVE divulgadas y parcheadas, verificadas en la NVD: CVE-2024-21626 (runc «Leaky Vessels»), CVE-2025-53773 (GitHub Copilot / Visual Studio), CVE-2025-59536 y CVE-2026-21852 (agente de código en terminal, parcheadas)
Clase de riesgo	Seguridad de la capa de ejecución de los agentes de código
Relevancia	Cualquiera que despliegue agentes de código, en terminal o conectados a MCP