Un enlace normal de ChatGPT podía convertirse en una puerta de entrada. Zenity Labs descubrió que una vulnerabilidad en el constructor de Workspace Agents permitía iniciar la creación de un agente autónomo controlado por un atacante tras un solo clic en un enlace de phishing, un cebo digital que parecía legítimo. OpenAI corrigió el fallo AgentForger el 8 de junio de 2026, antes de que se hiciera público el 23 de julio.
La amenaza, bautizada AgentForger, no afectaba a cualquier usuario por igual. Para funcionar, la víctima debía estar conectada a ChatGPT, tener acceso a los agentes del espacio de trabajo y contar con al menos una aplicación autorizada, como Gmail, Outlook o Slack. En esas condiciones, el agente podía actuar con los permisos de la persona y recibir nuevas órdenes sin otro clic.
Qué es un agente de Workspace
Los Workspace Agents son asistentes de IA que una empresa puede configurar para repetir tareas y mover trabajo entre herramientas. OpenAI permite probarlos antes de publicarlos, conectarlos a aplicaciones, compartirlos con el equipo y ejecutarlos de forma programada.
En la práctica, eso significa que un agente puede revisar información, preparar resúmenes o completar pasos de un flujo de trabajo sin que alguien tenga que empezar desde cero cada vez. Esa autonomía resulta útil, pero también aumenta el daño posible cuando las instrucciones o los permisos caen en manos equivocadas.
Cómo aprovechaba el constructor
AgentForger era una variante de la falsificación de solicitud entre sitios, conocida como CSRF. Este tipo de ataque engaña a una sesión ya iniciada para que realice una acción que el usuario no pretendía. Aquí, la acción no era un simple cambio de configuración, sino construir un nuevo agente.
Mike Takahashi, investigador de Zenity Labs especializado en poner a prueba sistemas de IA, explicó que el constructor aceptaba instrucciones iniciales incluidas dentro de una URL. Al abrir el enlace, esas órdenes podían enviarse automáticamente al sistema, seleccionar una plantilla, añadir aplicaciones conectadas, reducir las solicitudes de aprobación, publicar el agente y dejarlo programado.
El detalle clave era que las aplicaciones ya habían sido autorizadas por el empleado. Por eso no aparecía una nueva pantalla para conceder acceso. Era como entregar a alguien una llave válida, pero sin darse cuenta de que también se había creado un ayudante dispuesto a usarla.
El correo daba nuevas órdenes
Una vez publicado, el agente podía revisar el buzón de la víctima. Zenity configuró su prueba para buscar mensajes del atacante con un asunto concreto, ejecutar lo que pedían mediante las aplicaciones conectadas y devolver los resultados por correo.
El primer clic instalaba el mecanismo y la programación lo mantenía activo. Después, el atacante no necesitaba que la víctima volviera a abrir el enlace ni que dejara una pestaña encendida. El buzón funcionaba como un mando a distancia, discreto y persistente.
Lo que podía hacer AgentForger
Zenity probó el ataque en doce escenarios. El agente logró elaborar un mapa interno con personas, proyectos y reuniones, buscar documentos sensibles en correo y almacenamiento corporativo, localizar credenciales y enviar los resultados al atacante. Eran pruebas de concepto diseñadas para medir el alcance del fallo.
El sistema también podía actuar con la identidad del empleado. En las pruebas, envió mensajes internos de phishing, preparó intentos de fraude por correo empresarial y utilizó canales de confianza como Teams o Slack. Un mensaje externo suele levantar sospechas, pero uno que parece venir de un compañero puede pasar más fácilmente.
«No se trata de una solicitud falsificada, sino de un infiltrado falsificado», resumió Michael Bargury, cofundador y director de tecnología de Zenity. La frase señala el cambio principal. El atacante no obtenía solo una acción aislada, sino una herramienta autónoma con acceso, horario e instrucciones propias.
OpenAI lo corrigió en cuatro días
Zenity comunicó la vulnerabilidad a OpenAI mediante Bugcrowd el 4 de junio de 2026. El informe fue aceptado el 5 de junio y la corrección llegó el día 8, con la retirada del parámetro de URL que había permitido iniciar el ataque. La reparación estaba desplegada antes de la publicación de la investigación.
La rapidez importa porque el fallo afectaba a una función capaz de actuar sobre varias aplicaciones a la vez. El caso también muestra que un error pequeño en el proceso de creación puede multiplicarse cuando la IA tiene permisos amplios y trabaja de forma autónoma. Esa es la parte incómoda.
Qué deben vigilar las empresas
La documentación actual de OpenAI señala que las aplicaciones pueden pedir aprobación antes de actuar y advierte de que la opción de no preguntar eleva el riesgo. También recomienda limitar cada conexión a lo estrictamente necesario, sobre todo cuando un agente usa una cuenta compartida o puede enviar, editar o borrar contenido.
Los administradores pueden restringir qué personas usan cada aplicación, permitir solo acciones de lectura y revisar permisos por función. OpenAI también ofrece visibilidad sobre la actividad, las aplicaciones conectadas y los horarios de los agentes desde la consola de administración. Al final del día, la lección no es dejar de usar agentes, sino revisar quién puede crearlos, qué datos alcanzan, cuándo trabajan y qué acciones necesitan confirmación.
Un agente útil debe tener límites claros, igual que cualquier empleado con acceso sensible.
La investigación oficial sobre AgentForger se ha publicado en Zenity Labs.
