GhostApproval en agentes de código es la advertencia de que la aprobación humana no alcanza cuando el diff muestra una ruta y el sistema escribe en otra. El riesgo no está solo en una mala decisión del agente. Está en la UI, el sandbox y la ruta canónica que el agente toca realmente.

El 8 de julio de 2026, Wiz publicó "GhostApproval: A Trust Boundary Gap in AI Coding Assistants". La investigación reportó variaciones del patrón en 6 asistentes: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity y Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). Si usas Codex, Claude Code o agentes en CI, resuelve symlinks antes de confiar en el prompt.

Resumen práctico

  • GhostApproval reemplaza "aprobar el diff" por "confiar en la ruta canónica".
  • Un symlink dentro del repo puede apuntar a un archivo sensible fuera del workspace.
  • Sandbox, permisos y MCP deben validar el objetivo real, no solo la ruta aparente.
  • CI debe registrar symlinks sospechosos antes de aceptar un PR agentic.

Diagrama abstracto muestra rutas divergentes entre workspace y objetivo real sin texto visible.

¿Qué rompió realmente GhostApproval?

En 2026, Wiz reportó GhostApproval en 6 asistentes de código y dijo que 3 proveedores corrigieron el problema rápidamente: AWS, Cursor y Google (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", 2026). El patrón rompe la confianza entre la ruta que ve la persona y el archivo que recibe la escritura.

El ataque usa una idea antigua: un archivo dentro del workspace es, en realidad, un symlink hacia fuera. El agente lee instrucciones, decide editar el archivo aparente y la capa de ejecución sigue el enlace hasta un objetivo sensible, como configuración de shell o una clave de acceso.

La brecha peligrosa está entre "la persona aprobó" y "la persona entendió el objetivo real". Si la pantalla muestra un archivo local inofensivo, pero la escritura cae fuera del workspace, la aprobación se vuelve ceremonia. Existe formalmente, pero no comunica el riesgo.

Esto complementa la cuarentena de repositorio para agentes de código. La cuarentena decide cuándo un repo desconocido puede ejecutar. GhostApproval decide si una escritura ya autorizada todavía respeta el límite del workspace.

Cápsula citable: GhostApproval no es solo un bug de symlink. Es una falla de frontera en agentes de código: la persona aprueba una ruta aparente, mientras el runtime puede escribir en el objetivo resuelto fuera del workspace. La corrección debe unir UI, sandbox y resolución canónica.

¿Por qué la aprobación humana no basta cuando la ruta es falsa?

En 2026, MITRE describe CWE-451 como una UI que no representa información crítica correctamente, permitiendo que origen o contenido queden ocultos o falsificados (MITRE, "CWE-451", 2026). En GhostApproval, el prompt de aprobación falla justo ahí: no muestra el objetivo real de la escritura.

Wiz lo presenta como una falla de consentimiento informado. La persona sigue en el loop, pero el loop no entrega la información necesaria para decidir. En casos descritos por la investigación, el agente reconocía internamente el objetivo riesgoso mientras la interfaz mostraba solo el nombre benigno del archivo.

Para equipos de ingeniería, eso cambia la revisión. "El agente pidió aprobación" ya no es evidencia suficiente. La evidencia útil es otra: ruta aparente, ruta resuelta, operación prevista, permiso aplicado y alcance del sandbox.

También cambia cómo conviene pensar los modos automáticos. En marzo de 2026, Anthropic escribió que usuarios de Claude Code aprobaban el 93% de los prompts de permiso y que auto mode buscaba reducir fatiga de aprobación (Anthropic, "How we built Claude Code auto mode", 2026). Si casi todo se acepta, el prompt debe ser más confiable, no solo más frecuente.

Cápsula citable: La aprobación humana solo protege agentes de código cuando el prompt muestra el objetivo verdadero. MITRE clasifica la ocultación de información crítica como CWE-451; GhostApproval aplica esa debilidad al diff agentic, donde una ruta aparente puede ocultar el archivo resuelto.

En 2026, MITRE define CWE-61 como una falla al considerar que un archivo puede resolverse mediante symlink fuera de la esfera de control prevista (MITRE, "CWE-61", 2026). La auditoría correcta resuelve la ruta antes de escribir y bloquea cuando el objetivo sale del workspace autorizado.

Empieza por el inventario. Antes de dejar que el agente edite, pide o ejecuta una revisión de enlaces simbólicos en el repo. El objetivo no es prohibir todo symlink. Es separar symlinks esperados, como caché o worktree, de enlaces hacia home, .ssh, configuración del agente, credenciales o directorios de sistema.

En Linux y macOS, una revisión mínima compara la ruta del enlace con el objetivo real. Para revisión humana, lo importante es ver la resolución completa antes del diff:

find . -type l -print0 | while IFS= read -r -d '' link; do
  printf '%s -> %s\n' "$link" "$(realpath "$link")"
done

Luego aplica política. Los enlaces que resuelven fuera del repo entran en cuarentena. Los enlaces que resuelven a ~/.ssh, archivos de shell, configuración de IDE, claves de cloud o settings del agente deben bloquear escritura automática. Si el caso es legítimo, necesita justificación explícita.

Flujo abstracto muestra validación entre ruta aparente y ruta real sin texto visible.

Experiencia práctica: trato los symlinks como datos de entrada, no como detalle del filesystem. En un repo desconocido, el agente puede sugerir que "solo ajusta la configuración". Antes de editar, quiero ver el objetivo resuelto y la razón de ese enlace.

Cápsula citable: La defensa contra GhostApproval empieza con resolución canónica de ruta. CWE-61 describe el riesgo de operar en un archivo que resuelve fuera de la esfera prevista; en agentes de código, el diff debe mostrar el enlace y el objetivo real antes de aprobar.

¿Cómo ajustar Codex, Claude Code y MCP después de esto?

En 2026, la documentación de Codex dice que el agente corre con red desactivada por defecto y escrituras locales limitadas al workspace (OpenAI Developers, "Agent approvals & security", 2026). En modos como workspace-write con on-request, ese límite debe incluir la ruta resuelta, no solo el prefijo textual.

En Codex, evita danger-full-access en un repo que todavía no pasó por inventario de symlink. Si una tarea necesita escribir fuera del workspace, usa una excepción estrecha y revisable. La documentación de Codex diferencia acceso total de workspace-write con aprobación bajo demanda (OpenAI Developers, "Sandbox", 2026).

En Claude Code, usa permisos y sandbox juntos. La documentación de permisos dice que las reglas de symlink revisan dos rutas: el enlace y el objetivo resuelto (Claude Code Docs, "Configure permissions", 2026). Las reglas de allow pasan solo cuando ambos coinciden. Las reglas de deny bloquean si cualquiera coincide.

En sesiones largas, uso RemoteCode para ahorrar contexto en sesiones agentic con Codex y Claude Code. Ayuda cuando la triage necesita cruzar inventario, logs, permisos e historial sin repetir todo en el prompt principal. Es una herramienta mía, así que esta mención es editorial y ligada al costo real de contexto en loops de seguridad.

Para MCP, la regla es más estricta: negar por defecto hasta que el repo pase triage. La documentación de Claude Code permite negar toda herramienta MCP con mcp__* y liberar después un servidor específico (Claude Code Docs, "Configure permissions", 2026). Eso evita que una escritura local se convierta en efecto lateral en GitHub, navegador, cloud o tickets.

Cápsula citable: Después de GhostApproval, el sandbox de agente debe validar la ruta canónica. Codex documenta red apagada y escritura limitada al workspace por defecto; Claude Code documenta chequeos de symlink sobre enlace y objetivo. MCP debe empezar negado y liberarse por servidor.

¿Dónde debe entrar CI en esta defensa?

En mayo de 2026, GitHub dijo que Copilot code review había procesado más de 60 millones de revisiones (GitHub Blog, "Agent pull requests are everywhere", 2026). La misma fuente dice que más de una de cada cinco revisiones en GitHub involucraba un agente. Con ese volumen, la revisión de symlink debe automatizarse.

CI no reemplaza el sandbox local. Llega demasiado tarde para proteger la máquina de la persona desarrolladora. Aun así, protege el repositorio compartido y crea evidencia para revisión de PR. El chequeo debe fallar cuando un PR agrega un symlink hacia un objetivo fuera de directorios permitidos.

Una regla simple funciona: listar cada symlink nuevo o modificado, resolver su objetivo y publicar el resultado como artefacto de revisión. Si algún objetivo sale del repo, el PR necesita aprobación de seguridad. Si toca home, secretos, configuración del agente o archivos de inicio, bloquéalo.

Este control combina con evals de PR para agentes en CI y hooks que frenan agentes de código. La diferencia es que el chequeo de symlink no mide calidad del código. Mide si el diff representa la escritura real.

Cápsula citable: CI debe tratar un symlink como cambio de frontera, no como detalle de archivo. GitHub reporta decenas de millones de revisiones con agente; con ese volumen, cada PR agentic necesita exponer enlace simbólico, objetivo resuelto y decisión de bloqueo antes del merge.

¿Qué checklist usar en el próximo repo?

En 2025, el Stack Overflow Developer Survey dijo que el 84% de respondientes usaba o planeaba usar herramientas de IA en desarrollo (Stack Overflow, "2025 Developer Survey: AI", 2025). La misma encuesta mostró 51% de profesionales usándolas diariamente. En 2026, Stack Overflow reportó uso diario de IA en el trabajo en 58% (Stack Overflow Blog, "Domain expertise still wanted", 2026). Esa escala exige checklist repetible.

Usa este flujo antes de aceptar edición de agente en repo desconocido o PR generado por agente:

  • Lista symlinks y registra el objetivo resuelto de cada uno.
  • Bloquea escrituras automáticas si el objetivo sale del workspace.
  • Niega cualquier objetivo en home, .ssh, shell, credenciales, IDE, .git, .claude o MCP.
  • Muestra la ruta aparente y la ruta canónica en el prompt de aprobación.
  • Ejecuta el agente con red apagada hasta terminar la triage.
  • Mantén MCP negado hasta saber por qué cada servidor es necesario.
  • Haz fallar CI cuando un nuevo symlink apunta fuera del repo.
  • Exige revisión humana específica para excepciones documentadas.
Señal en el PR Decisión práctica
El symlink apunta dentro del repo y tiene motivo claro Permítelo con revisión normal del diff.
El symlink apunta fuera del workspace Bloquea escrituras automáticas y pide aprobación de seguridad.
El symlink toca shell, SSH, credencial, .git, .claude o IDE Bloquea el PR hasta remover o justificar el objetivo.
El agente pide MCP antes de la triage Niega la herramienta y registra la necesidad real.

Checklist abstracto muestra etapas de validación para agentes de código sin texto visible.

El error común es pensar que "no usamos Windsurf" o "no usamos Amazon Q" lo resuelve. GhostApproval es una clase de diseño. La pregunta correcta es: tu herramienta muestra el objetivo real antes de escribir, y tu entorno bloquea cuando ese objetivo cruza la frontera?

Cápsula citable: El checklist mínimo para GhostApproval combina inventario de symlink, resolución canónica, bloqueo fuera del workspace, MCP negado por defecto y falla explícita en CI. La adopción diaria de IA por desarrolladores convierte este control en operativo, no opcional.

Preguntas frecuentes (FAQ)

¿GhostApproval afecta solo a Claude Code?

No. En 2026, Wiz reportó variaciones en 6 asistentes de código: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity y Windsurf (Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants"). El punto práctico es auditar tu herramienta actual, porque la falla vive entre UI, symlink y runtime.

¿Actualizar la herramienta resuelve todo?

No por sí solo. En 2026, AWS publicó CVE-2026-12958 y corrigió la falla en Language Servers for AWS 1.69.0 (AWS Security Bulletin 2026-047-AWS). Actualizar reduce riesgo de producto, pero tu flujo aún necesita resolver symlink, limitar workspace, revisar MCP y bloquear en CI.

¿Qué archivo es más peligroso en este ataque?

No existe un único archivo. En 2026, NVD describió CVE-2026-12958 como escritura arbitraria fuera de la frontera del workspace mediante symlink malicioso (NVD, "CVE-2026-12958"). En la práctica, trata archivos de shell, claves SSH, credenciales, settings del agente, hooks de Git y archivos de IDE como sensibles.

Sí, con política. En 2026, la documentación de Claude Code dice que las reglas allow para symlink exigen que enlace y objetivo coincidan (Claude Code Docs, "Configure permissions"). Las reglas deny bloquean si cualquiera coincide. Un monorepo puede usar symlinks legítimos, pero necesita objetivo canónico y motivo.

Fuentes

  • Wiz, "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", consultado en 2026-07-11, https://www.wiz.io/blog/ghostapproval-a-trust-boundary-gap-in-ai-coding-assistants
  • AWS, "CVE-2026-12957 and CVE-2026-12958 - Issues in Language Servers for AWS and Amazon Q Developer Plugins", consultado en 2026-07-11, https://aws.amazon.com/security/security-bulletins/2026-047-aws/
  • GitHub Advisory Database, "Arbitrary file write in Language Servers for AWS", consultado en 2026-07-11, https://github.com/aws/language-servers/security/advisories/GHSA-6v3r-4p5c-mrp5
  • NVD, "CVE-2026-12958", consultado en 2026-07-11, https://nvd.nist.gov/vuln/detail/CVE-2026-12958
  • MITRE, "CWE-61: UNIX Symbolic Link (Symlink) Following", consultado en 2026-07-11, https://cwe.mitre.org/data/definitions/61.html
  • MITRE, "CWE-451: User Interface (UI) Misrepresentation of Critical Information", consultado en 2026-07-11, https://cwe.mitre.org/data/definitions/451.html
  • OpenAI Developers, "Agent approvals & security", consultado en 2026-07-11, https://developers.openai.com/codex/agent-approvals-security
  • OpenAI Developers, "Sandbox", consultado en 2026-07-11, https://developers.openai.com/codex/concepts/sandboxing
  • Claude Code Docs, "Configure permissions", consultado en 2026-07-11, https://code.claude.com/docs/en/permissions
  • Anthropic, "How we built Claude Code auto mode", consultado en 2026-07-11, https://www.anthropic.com/engineering/claude-code-auto-mode
  • GitHub Blog, "Agent pull requests are everywhere. Here's how to review them", consultado en 2026-07-11, https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/
  • Stack Overflow, "2025 Developer Survey: AI", consultado en 2026-07-11, https://survey.stackoverflow.co/2025/ai
  • Stack Overflow Blog, "Domain expertise still wanted: the latest trends in AI-assisted knowledge for developers", consultado en 2026-07-11, https://stackoverflow.blog/2026/03/16/domain-expertise-still-wanted-the-latest-trends-in-ai/