Estamos acostumbrados a leer sobre la IA en ciberseguridad desde un solo ángulo: un atacante que usa agentes para moverse más rápido. El segundo ángulo importa más a tu organización y recibe mucha menos atención. El agente que ejecutas en el equipo de tu propio desarrollador es en sí mismo una nueva superficie de ataque. En dos meses, tres grupos de investigación independientes publicaron hallazgos que apuntan todos en la misma dirección.

Lo que comparten estos casos no es un fallo del modelo ni una mala respuesta. El agente nunca salió de su sandbox ni infringió ninguna regla. Lo que ocurrió es que el agente leyó o escribió un archivo dentro del proyecto y, después, una herramienta de confianza que se ejecuta fuera del sandbox ejecutó el contenido de ese archivo. El sandbox resistió. El compromiso lo rodeó.

El mecanismo: un ajuste de rendimiento de Git con años de antigüedad

El ejemplo más claro lo publicó Manifold Security el 2 de septiembre de 2026 con el nombre GitSpawn. Gira en torno a un ajuste de Git por proyecto llamado core.fsmonitor, una opción de rendimiento legítima y documentada cuyo valor es un comando que Git ejecuta para identificar rápidamente los archivos modificados en lugar de recorrer todo el directorio.

Ahora junta las dos mitades:

  • Un agente de programación con IA, cuando empieza a trabajar en un proyecto, ejecuta automáticamente comandos de Git como git status y git diff para entender el estado del repositorio. Es un comportamiento normal y necesario.
  • Si el repositorio lleva un valor malicioso de core.fsmonitor, el simple hecho de ejecutar esos comandos ejecuta el comando del atacante.

El resultado es que abrir un repositorio de código deja de ser un acto de lectura y se convierte en un acto de ejecución. Sin clic, sin aprobación, sin ningún aviso mostrado al desarrollador. Según el informe, ocho agentes de línea de comandos quedaron expuestos, y para varios llegaron parches: goose en la 1.44.0, Claude Code en la 2.1.196 para la vía de core.fsmonitor, Codex CLI en la 0.131.0, además de Cursor. El informe señaló cuatro vías todavía sin parche en el momento de la publicación. La clase se rastreó bajo identificadores como CVE-2026-72718, CVE-2026-19592 y CVE-2026-55607.

No es un incidente aislado, sino toda una clase

Seis semanas antes de GitSpawn, investigadores de Pillar Security publicaron el 20 de julio de 2026 una serie que llamaron una semana de escapes de sandbox, en la que documentaron siete vulnerabilidades en cuatro agentes de programación de tres proveedores: Cursor, Codex, Gemini CLI y Antigravity. Su descripción del mecanismo merece leerse dos veces. El agente permanece dentro de la caja y cumple todas las reglas. Simplemente escribe un archivo que una herramienta de confianza fuera de la caja ejecuta, carga o analiza más tarde.

  • En Cursor, un archivo de configuración de hooks controlado por el espacio de trabajo permitía la ejecución fuera del sandbox, registrado como CVE-2026-48124 y corregido en la versión 3.0.0.
  • En Codex CLI, la lista de comandos permitidos confiaba en git show solo por su nombre, aunque los parámetros que se le pasan pueden hacer que sea algo más que de solo lectura. Corregido en la versión 0.95.0.
  • Un problema con el socket de Docker afectaba a la vez a Codex, Cursor y Gemini CLI.
  • En Antigravity, una evasión de la lista de bloqueo de Seatbelt de macOS y un problema de configuración de tareas del editor, ambos clasificados por Google como difíciles de explotar.

Después, el 10 de septiembre de 2026, Upstarts Media informó de una tercera divulgación, de una startup llamada Accomplish, sobre sandboxes con fugas en Claude Code, Codex y Cursor. La cifra interesante ahí no es la vulnerabilidad sino el tiempo de corrección: el problema de Cursor se resolvió en aproximadamente una semana, dos problemas de OpenAI en agosto, mientras que el de Anthropic tardó unos cincuenta días a lo largo de decenas de versiones. Tres grupos de investigación, tres informes, dos meses, un mismo patrón.

Por qué importa aunque nunca escribas código

Porque el riesgo no recae en el agente. Recae en el equipo que lo ejecuta y en la red en la que se encuentra ese equipo. La estación de trabajo de un desarrollador es uno de los dispositivos con más privilegios de cualquier empresa: guarda claves de acceso a servidores, tokens de despliegue y, a menudo, una conexión abierta a una base de datos de producción. Ejecutar un solo comando en ella no es un asunto menor.

El escenario no es teórico en el mercado saudí. Contrasta estos casos con tu propia empresa:

  • Un contratista externo o una agencia de desarrollo entrega código que tu equipo abre después con un agente de IA en un equipo dentro de tu red.
  • Un proyecto de código abierto que un desarrollador descarga para probar una biblioteca o una solución rápida.
  • Un archivo enviado por correo electrónico o WhatsApp por un proveedor, descomprimido y abierto directamente en el editor.
  • Un candidato a un empleo que presenta un proyecto de muestra que abre un revisor técnico.
  • Una rama antigua o un repositorio transferido entregado durante una adquisición o un traspaso de proyecto.

En todos ellos, la suposición implícita es que abrir archivos para leerlos es un acto seguro. Esa suposición es la que se ha roto.

Qué hacer esta semana

Cinco pasos, y el primero no necesita presupuesto:

  1. Actualiza hoy las herramientas de agentes en todo el equipo. Existen parches para la mayoría de estas herramientas, y el valor está en que todos estén en una versión parcheada, no solo una persona. Empieza por saber quién ejecuta qué y en qué versión, porque ese inventario en sí suele faltar.
  2. Trata el código entrante como contenido no fiable. El código de un contratista o de una fuente abierta no es un documento que lees, es algo que se ejecuta. Ábrelo la primera vez en un equipo o contenedor separado de la red de trabajo.
  3. Separa el equipo de desarrollo de las claves de producción. No guardes tokens de servidores en producción en el equipo donde se abren proyectos de origen externo. Así la pérdida se queda dentro de ese dispositivo.
  4. Canaliza el despliegue a través de un pipeline central, no de un portátil personal. Cuando el despliegue pasa por un único pipeline de compilación con permisos acotados, comprometer un solo equipo deja de ser un camino hacia producción.
  5. Añade una cláusula a los contratos de desarrollo externalizado. Tienes derecho a especificar cómo se entrega el código y desde qué repositorio, y a exigir al proveedor que mantenga sus herramientas actualizadas. Es una condición contractual, no un debate técnico.

A nivel local, nada de esto es una buena práctica opcional. Los Controles Esenciales de Ciberseguridad emitidos por la Autoridad Nacional de Ciberseguridad (NCA) incluyen dominios explícitos para la seguridad de endpoints, la seguridad de la gestión de cambios y del desarrollo, y la seguridad de terceros, mientras que la responsabilidad por la protección de los datos personales sigue recayendo en la organización conforme a la Ley de Protección de Datos Personales (PDPL). Si la puerta se abrió a través del equipo de un desarrollador que abrió un proyecto de un proveedor, eso no reduce la responsabilidad.

La visión de Origami

Leemos estos tres informes como una corrección a una idea que se extendió rápidamente: que un sandbox basta mientras el agente esté encerrado en él. Estas vulnerabilidades no rompieron el aislamiento. Usaron un puente legítimo que lleva algo escrito dentro de la caja hasta una herramienta que se ejecuta fuera de ella. Lo que significa que la pregunta correcta no es si el agente está en un sandbox, sino qué herramientas leen lo que produce el agente y con qué privilegios se ejecutan esas herramientas.

Una observación práctica de lo que vemos en nuestros clientes: la adopción de herramientas de IA dentro de los equipos de desarrollo va meses por delante de cualquier política que la regule. Un desarrollador prueba una herramienta, le gusta, y pasa a formar parte del flujo de trabajo diario sin decisión, sin revisión y sin inventario. El problema no es la herramienta. El problema es que entró por una puerta que nadie vigila. Cuando revisamos los entornos de los clientes empezamos exactamente aquí: qué herramientas se ejecutan realmente en los equipos del personal, con qué privilegios, y qué pasa si esta noche se ejecuta un comando en uno de ellos. Si quieres una revisión desde ese ángulo, nos encontrarás en la página de contacto.

En resumen

Tres divulgaciones independientes en dos meses dicen lo mismo: un agente de programación con IA convierte la apertura de un proyecto de una lectura en una ejecución, y basta con que un tercero coloque una línea en un archivo de configuración. Se publicaron parches para la mayoría de las herramientas y algunas vías siguieron abiertas, pero la lección sobrevive a cualquier versión. Cualquier herramienta que ejecutes en un equipo con muchos privilegios forma parte de tu superficie de ataque, la mencionen o no tus políticas. Empieza con una pregunta: ¿quién de tu equipo está ejecutando ahora mismo un agente de IA, en qué equipo y en qué versión?

Fuentes