Por muy autosuficiente que sea una IA, la aprobación humana es esencial.

Casi todos los asistentes de código con IA funcionan con la misma promesa de seguridad: antes de hacer algo delicado, el agente le pregunta a una persona. “¿Aplico este cambio?” y la persona decide.

Es un buen principio. Pero una investigación reciente muestra que, si la pregunta no refleja lo que realmente va a pasar, la aprobación humana deja de ser un control y se vuelve un trámite.

Qué encontró Wiz Research

En julio de 2026, Wiz Research, uno de los equipos de investigación en seguridad cloud más reconocidos, publicó GhostApproval. El estudio encontró el mismo patrón de vulnerabilidad en seis de los principales asistentes de código con IA: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity y Windsurf.

El ataque es simple, y eso lo hace preocupante.

1. Un repositorio con trampa. El atacante publica un proyecto con un archivo de apariencia inocente, por ejemplo project_settings.json. Pero no es un archivo real: es un enlace simbólico, una especie de acceso directo que apunta a otro lugar del equipo. En el ejemplo, a ~/.ssh/authorized_keys, el archivo que define quién puede entrar al computador sin contraseña.
2. Una instrucción normal. El desarrollador clona el repositorio y le pide al agente algo cotidiano, como “sigue las instrucciones del README”. El README le indica al agente que modifique ese archivo de configuración.
3. Una aprobación engañosa. El agente pide permiso y el desarrollador ve algo como: “¿Aplico este cambio a project_settings.json?”. Parece una edición local sin riesgo, así que aprueba.
4. El resultado. El agente escribe la llave del atacante en el archivo de accesos del sistema. El atacante queda con entrada al equipo sin contraseña.

Lo grave no es el truco: es lo que muestra la pantalla

Los enlaces simbólicos existen desde hace décadas, y el truco en sí no es nuevo. Lo que hace relevante a GhostApproval es otra cosa:

El diálogo de confirmación mostraba un archivo mientras el agente escribía en otro.

Y hay dos detalles que agravan el problema:

• En varios casos el agente sabía la verdad: Su razonamiento interno reconocía que el archivo era en realidad otra cosa. En un ejemplo documentado, el agente anotó que project_settings.json era en realidad un archivo de configuración del sistema, pero la pregunta que vio el usuario solo mencionaba project_settings.json. La información existía; simplemente no llegó a la persona que tenía que decidir.
• En dos herramientas la escritura ocurría antes de la aprobación: El cambio se guardaba en disco antes de que aparecieran los botones de aceptar o rechazar. Como lo resumen los investigadores: el diálogo de confirmación no era una barrera de autorización, era un mecanismo para deshacer.

Este tipo de falla tiene nombre en el catálogo de vulnerabilidades de software: CWE-451, representación engañosa de información crítica en la interfaz. Es decir, la persona decide bien sobre información equivocada.

La mayoría de los fabricantes ya publicó correcciones y otros las tenían en curso al momento de la publicación. Pero lo importante no es qué herramienta falló, sino lo que el patrón revela.

La lección: un control humano vale lo que vale la información que recibe

En los últimos meses hemos escrito varias veces que el juicio humano es el control que no se puede delegar a una IA. GhostApproval agrega un matiz importante: no basta con que exista un punto de aprobación. Para que ese control sea real tiene que cumplir tres condiciones.

1. Mostrar la verdad, no una versión simplificada. Si el sistema sabe algo relevante para la decisión, la persona que aprueba tiene que verlo. Un control que oculta información no es un control.
2. Ocurrir antes, no después. Aprobar tiene que ser una condición para actuar, no una oportunidad de deshacer. Si la acción ya ocurrió, la aprobación es cosmética.
3. Dejar rastro. Quién aprobó qué, cuándo y sobre qué información. Sin ese registro no hay forma de auditar ni de aprender de un error.

Para organizaciones que operan software crítico, como banca, previsión, seguros o retail financiero, esto no es un detalle técnico. Es la diferencia entre un proceso gobernado y uno que solo lo parece.

Un agente sin trazabilidad no reduce el riesgo: lo cambia de lugar

La IA está acelerando todo el ciclo de desarrollo, y eso es bueno. Pero cada nuevo agente que actúa sobre repositorios, archivos o sistemas es también un nuevo actor con permisos. Si sus acciones no son visibles ni auditables, el riesgo no desaparece: se mueve a un lugar donde nadie lo está mirando.

Por eso vale la pena hacerse, sobre cualquier agente que use su organización, las mismas preguntas que se harían sobre una persona con acceso privilegiado: ¿qué puede tocar?, ¿quién autoriza lo que hace?, ¿dónde queda el registro?

Tres prácticas que ya deberían ser estándar

Los investigadores de Wiz proponen medidas concretas para los fabricantes. Nosotros creemos que cualquier equipo que use agentes sobre sus repositorios debería exigirlas:

• Resolver la ruta real antes de mostrar cualquier confirmación: La persona tiene que ver el destino verdadero del cambio, no el nombre aparente.
• Alertar explícitamente cuando una acción sale del proyecto: Escribir fuera del espacio de trabajo nunca debería pasar desapercibido.
• No escribir nada antes de la autorización: La confirmación es una barrera, no un “deshacer”.

Y para los equipos de desarrollo, algunas medidas de higiene básica:

• Tratar con precaución cualquier repositorio de origen desconocido, especialmente antes de pedirle a un agente que “siga las instrucciones”.
• Revisar con atención las rutas que muestra cada solicitud de aprobación.
• Monitorear los archivos sensibles del sistema, como los de acceso SSH y configuración de la terminal, con herramientas de integridad de archivos.

Cómo lo abordamos en Tinet

Suite Loica se diseñó sobre estos mismos principios, en la etapa del ciclo donde trabaja.

Loica no programa. Pone el plano antes de programar (GenDEV) y la revisión después (GenQA). En el medio, el equipo del cliente trabaja como siempre, con sus propias herramientas y controles.

• La aprobación es una barrera real: En cada etapa, desde la idea hasta el diseño técnico y la certificación, hay una persona que revisa el artefacto completo y aprueba antes de avanzar. Loica propone y el equipo decide. Si algo falla o no cumple, no se publica.
• La persona aprueba lo que realmente se va a usar: Las especificaciones se construyen sobre el código real del cliente, a través de la KDB, la memoria de la empresa. Así, quien aprueba ve qué ya existe, qué depende de qué y qué se va a ver afectado, no un resumen optimista.
• Todo deja rastro: Cada cambio guarda su historia: quién lo pidió, para qué y quién lo aprobó. GenQA, además, deja evidencia en fotos y video de cada prueba.
• El conocimiento se queda en casa: La KDB vive solo en la infraestructura del cliente, en sus computadores o en su nube.

No creemos que exista un agente perfecto, ni el nuestro. Lo que sí creemos es que el proceso alrededor del agente tiene que estar diseñado para que una persona informada tome la decisión final, y para que esa decisión quede registrada.

Para cerrar

GhostApproval no demuestra que la IA sea insegura. Demuestra que la confianza en un agente depende de algo muy concreto: que lo que ve la persona sea lo que realmente va a pasar.

En Tinet llevamos más de 25 años construyendo software que no puede fallar. La IA cambió la velocidad, no el estándar.

Si quiere revisar cómo se están aprobando hoy las acciones de IA en su ciclo de desarrollo, le proponemos una conversación de 45 minutos con nuestro equipo, sobre su realidad y sin presentaciones. La primera conversación es un diagnóstico, no una demo.

Fuente: "GhostApproval: A Trust Boundary Gap in AI Coding Assistants", Wiz Research, julio 2026.