GhostApproval: cuando el cuadro de aprobación de tu agente de código te miente

Todo el modelo de seguridad de un agente de código con IA descansa en una premisa simple: antes de que el agente escriba algo en tu disco, te muestra qué va a escribir y dónde, y vos decidís si confiar. A principios de julio, investigadores de Wiz publicaron una falla — la bautizaron GhostApproval — que rompe esa premisa en seis de las herramientas más usadas del mercado. El agente pide permiso para editar un archivo con pinta inocente. El permiso se concede. Pero lo que realmente se escribe es otra cosa, en otro lugar, y el desarrollador nunca se entera hasta que ya es tarde.

Cómo funciona el truco

La técnica se apoya en un mecanismo de Unix que tiene más de cuarenta años y que ya causó dolores de cabeza en condiciones de carrera, gestores de paquetes y escapes de contenedores: el símlink, o enlace simbólico. Un símlink es un archivo cuyo contenido real es, simplemente, "andá a buscar el contenido a esta otra ruta". Cuando un programa escribe en el símlink sin resolverlo primero, en realidad está escribiendo en el destino.

Wiz construyó un repositorio trampa con un archivo llamado project_settings.json que, en realidad, es un símlink que apunta a ~/.ssh/authorized_keys — el archivo que define qué claves pueden iniciar sesión por SSH en esa máquina sin contraseña. El README del repositorio le pide al agente, en lenguaje perfectamente normal, que "agregue una línea de configuración" a project_settings.json. Esa línea es, en realidad, la clave pública SSH del atacante disfrazada de parámetro de configuración. Si el desarrollador clona el repositorio y le pide al agente que "arme el workspace" o "siga las instrucciones del README", el agente escribe la clave a través del símlink directo al archivo de autenticación SSH. A partir de ahí, si la máquina expone el servicio SSH, el atacante entra sin contraseña. Una variante del mismo truco apunta al archivo de arranque de la shell (~/.zshrc), que se ejecuta la próxima vez que el usuario abre una terminal — ni siquiera hace falta SSH.

El símlink es el vehículo; el problema real es el diálogo

Los trucos de símlinks son viejos y conocidos. Lo que hace nuevo a GhostApproval es dónde falla la defensa: en el cuadro de confirmación que se supone protege al usuario. Wiz probó Claude Code y encontró que el propio razonamiento interno del agente ya había identificado que project_settings.json era, en sus palabras, "en realidad un archivo de configuración de zsh". Pero el diálogo que se le mostró al desarrollador solo mencionaba el nombre inofensivo del archivo. El agente sabía. El usuario, no.

Wiz llama a esto un bypass de consentimiento informado: el humano sigue en el loop de aprobación, pero el loop le muestra información falsa. Y no todas las herramientas llegan siquiera a mostrar un diálogo a tiempo. En las pruebas de Wiz, Windsurf escribe el archivo en disco antes de mostrar los botones de aceptar o rechazar, así que el cuadro que aparece después es apenas un botón de deshacer con la clave ya instalada. Augment directamente no mostró ningún diálogo y leyó silenciosamente un archivo de credenciales de AWS que estaba fuera del proyecto.

Seis agentes, un mismo punto ciego

Las herramientas afectadas fueron Amazon Q Developer, Claude Code de Anthropic, Augment, Cursor, Google Antigravity y Windsurf. Al momento de la publicación de Wiz, Amazon Q (parche en el Language Server 1.69.0, con CVE-2026-12958), Cursor (v3.0, CVE-2026-50549) y Google Antigravity ya habían corregido el problema. Augment y Windsurf lo reconocieron sin tener todavía un parche. Anthropic fue la única que discutió la clasificación: sostuvo que el escenario "cae fuera de nuestro modelo de amenaza" porque el desarrollador ya eligió confiar en la carpeta al iniciar la sesión, y que la advertencia de símlink que Claude Code muestra hoy se había enviado en la versión 2.1.32 de febrero, como endurecimiento de rutina y no como respuesta al reporte.

Lo más revelador no es qué vendor respondió mejor, sino que el mismo patrón haya aparecido dos veces de forma independiente: en mayo, investigadores de Adversa AI ya habían publicado una técnica casi idéntica bajo el nombre SymJack, contra Claude Code, Cursor, Antigravity, GitHub Copilot, Grok Build y Codex CLI de OpenAI. Dos equipos distintos, meses aparte, llegando al mismo hallazgo: no es el error de un fabricante, es un punto ciego de toda la categoría. Los agentes siguen símlinks con operaciones de archivo comunes y después piden aprobación basándose en la ruta que se les mostró, no en la ruta donde realmente aterriza la escritura. Esto se suma a otros hallazgos recientes en la misma línea — desde el worm Miasma, que plantó archivos de configuración maliciosos en un repositorio de Microsoft Azure para que el payload corriera apenas alguien abría el proyecto en un agente de código, hasta fallas de shell injection como GuardFall que explotan comportamientos de bash igual de antiguos.

Por qué esto le importa a un shop que recién está adoptando estos agentes

Si tu equipo viene evaluando llevar un agente de código a producción — y más si lo hace en un entorno donde ese agente va a tener acceso a servidores, credenciales de bases de datos o llaves de acceso a sistemas legados como IBM i — GhostApproval es un recordatorio incómodo pero útil: el "humano en el loop" que suele citarse como red de seguridad solo funciona si el loop dice la verdad. Un cuadro de aprobación que nombra el archivo equivocado no es una salvaguarda, es una formalidad que da falsa confianza. Esto no invalida el uso de estos agentes, pero sí cambia qué controles hay que exigir antes de darles acceso amplio a un entorno de trabajo real.

Conclusión práctica

Hay pasos concretos que se pueden aplicar esta semana, sin esperar a que cada vendor termine de parchear. Primero, actualizar las herramientas de código con IA que ya estén en uso — Amazon Q, Cursor y Antigravity ya tienen parche disponible, y conviene confirmar la versión instalada en vez de asumir que la actualización llegó sola. Segundo, correr estos agentes con acceso a archivos limitado, o directamente dentro de un sandbox o contenedor, en particular cuando se trabaja sobre un repositorio que no es propio o recién se clonó. Tercero, antes de pedirle a un agente que "arme el workspace" o "siga el README" de un repositorio externo, darle una revisión manual rápida a ese README y a los archivos de configuración ocultos: es exactamente donde se esconde este tipo de instrucción. Y cuarto, después de trabajar en un repositorio desconocido, revisar a mano los archivos que este ataque específico apunta —y que no van a aparecer en git status porque están fuera del proyecto—: el archivo de arranque de la shell, las llaves SSH y la configuración propia de la herramienta de IA. Un ls -la ~/.zshrc ~/.ssh/authorized_keys para comparar fechas de modificación contra lo esperado alcanza para detectar si algo cambió mientras el agente estaba trabajando. Ninguno de estos cuatro pasos depende de que el proveedor termine de resolver el problema de fondo: son controles que un equipo puede aplicar hoy, independientemente de qué agente termine eligiendo.