Un desarrollador clona un repositorio desconocido, pide a un agente de programación que lo configure y acepta un cambio en un archivo que parece inofensivo. El problema es que el agente puede actuar sobre algo que el cuadro de aprobación no muestra. Si ese archivo es un enlace simbólico, la escritura puede acabar fuera del proyecto, por ejemplo en una configuración de shell o en un archivo de acceso SSH.

Flujo de agente de programación con sandbox y secretos protegidos fuera del límite

Esa es la lección incómoda de GhostApproval, la investigación publicada por Wiz el 8 de julio. El mismo día, AI Now Institute publicó Friendly Fire, un proof-of-concept que convierte un uso defensivo de Claude Code CLI y OpenAI Codex CLI en una ruta hacia ejecución remota de código. Juntas, las dos alertas dicen algo claro: las herramientas de AI coding ya no son solo autocompletado. En muchas empresas son runtimes locales con acceso a archivos, shell, gestores de paquetes, red, credenciales y decisiones de revisión.

No significa que sean inútiles. Significa que el modelo de confianza anterior no basta. Si una herramienta lee texto de repositorios no confiables, ejecuta pasos, edita archivos y pide al humano aprobar una acción resumida, debe tratarse como un runner de CI, un agente de build o una extensión privilegiada del IDE.

De asistente a runtime

Los primeros asistentes completaban líneas. Los agentes modernos recorren repositorios, abren archivos, deducen pasos de instalación, editan código, ejecutan pruebas, instalan dependencias y a veces reducen las aprobaciones. Esa es la ventaja. También es la superficie de ataque.

Una máquina de desarrollo contiene claves SSH, credenciales cloud, tokens de paquetes, repositorios internos, sesiones de navegador, VPN y configuración de shell. Un agente que puede escribir y ejecutar comandos allí no está solo sugiriendo código. Está operando dentro de un entorno sensible.

La seguridad ya tiene patrones para esto: runners aislados, credenciales con alcance limitado, reglas de red, sandboxes para código no confiable. Los agentes de programación necesitan lo mismo.

GhostApproval explicado

Wiz dice que GhostApproval afectó a seis asistentes: Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity y Windsurf. La técnica usa enlaces simbólicos, una función antigua de Unix. Un archivo parece estar dentro del proyecto, pero apunta a otro lugar. Si la herramienta escribe a través de ese enlace, modifica el destino real.

Wiz describe dos fallos combinados: seguimiento de symlinks, CWE-61, y representación engañosa en la interfaz, CWE-451. En varios casos, el sistema podía conocer el destino real, pero el diálogo mostrado al usuario no lo indicaba con claridad. El usuario aprobaba una edición local aparente, mientras la escritura podía tocar un archivo fuera del workspace.

Según Wiz, AWS, Cursor y Google corrigieron rápido. Amazon Q Developer language server antes de 1.69.0 aparece como afectado y corregido en 1.69.0, CVE-2026-12958. Cursor antes de 3.0 aparece como afectado y corregido en 3.0, CVE-2026-50549. Augment y Windsurf estaban en progreso en el momento de la publicación. Anthropic rechazó el reporte como fuera de su threat model, según Wiz.

La tabla de proveedores puede cambiar. El problema de fondo no: si la interfaz enseña una ruta amable y el runtime escribe en otra, la aprobación humana pierde valor.

Friendly Fire y el review de código ajeno

Friendly Fire apunta a una costumbre muy tentadora: pedir al agente que revise una biblioteca de terceros por seguridad.

AI Now afirma que su PoC permite ejecución remota de código en Claude Code CLI y OpenAI Codex CLI cuando se usan para evaluar bibliotecas open source o de terceros. El ataque, según el brief, no necesita un servidor MCP malicioso ni plugins. Usa prompt injections distribuidas en archivos normales del repositorio que el agente está leyendo.

No hace falta publicar pasos explotables para entender el riesgo. El repositorio deja de ser entrada pasiva. Si el agente lee texto hostil y luego usa herramientas según ese contexto, el repositorio forma parte del canal de control.

Confianza y opacidad

La misma semana, CNA informó de una advertencia china sobre un supuesto riesgo de "security backdoor" en Claude Code. Anthropic lo describió como una medida antiabuso basada en señales como zona horaria y proxy para regiones no soportadas. No es la misma historia que GhostApproval, pero entra en la misma conversación empresarial: las compañías quieren saber qué ve una herramienta local, qué envía, cómo aplica políticas y qué documenta el proveedor.

También hay una discusión de desarrolladores. Un hilo de Hacker News sobre el "Extended Thinking" de Claude Code reunió cientos de comentarios antes de estas alertas. No prueba GhostApproval, pero muestra una preocupación real: si la superficie visible de una herramienta es un resumen o una representación, ¿qué tanto puede confiarse en ella cuando aprueba cambios?

La adopción va por delante del control

Dark Reading cita el GitLab 2026 AI Accountability Report: 91% de las organizaciones usan dos o más herramientas de coding, y 54% usan tres o más. También cita datos de SonarSource: 72% de los desarrolladores que probaron estas herramientas las usan a diario; 96% no confía en que el código generado sea correcto tal cual; solo 48% siempre revisa antes de commitear.

Son encuestas, no leyes. Pero la tendencia es clara. Muchas empresas aprobaron varias herramientas antes de tener una política común. Una en el IDE, otra en terminal, otra en pull requests, otra informal. Cada una tiene su sandbox, UI de aprobación, telemetría y política.

Qué hacer ahora

Inventario primero. ¿Qué herramientas están permitidas? ¿Qué versiones? ¿Cuáles pueden ejecutar shell, editar archivos, acceder a red, leer secretos o invocar MCP?

Desactiva auto-approve y auto-review para repositorios no confiables. Si el código viene de internet, de un proveedor, de un candidato, de un cliente o de una dependencia sospechosa, trata el texto como hostil para el agente.

Usa entornos desechables: contenedores, VMs de desarrollo o workspaces cloud con límites. No pongas allí claves SSH personales, credenciales cloud de producción ni tokens largos si no hacen falta.

Separa secretos. Usa credenciales de corta vida, mínimo privilegio y escaneo de secretos antes de commits. Limita la salida a internet. Guarda logs de comandos, escrituras, aprobaciones, rechazos y llamadas de herramientas.

Qué deben demostrar los proveedores

No basta con decir "el usuario aprobó". El usuario debe aprobar información correcta sobre la operación real.

Los productos necesitan mostrar rutas canónicas, bloquear escapes del workspace, tratar symlinks con seguridad, avisar de objetivos externos, usar defaults seguros para repositorios no confiables, publicar estados claros de CVE y ofrecer controles empresariales auditables.

Las medidas antiabuso y la telemetría también deben estar documentadas. Los equipos aceptan controles cuando son visibles y limitados. Confían menos cuando un agente local parece inspeccionar señales del entorno sin que el despliegue lo entienda.

AI coding seguirá. La diferencia estará entre quienes lo traten como autocomplete y quienes lo traten como automatización privilegiada: sandbox, credenciales estrechas, red limitada, aprobaciones honestas y logs.