Un investigador de seguridad alertó sobre un ataque entre agentes Gemini posible dentro del entorno de agentes de IA para desarrollo. El hallazgo apunta a cómo una interacción aparentemente inocua entre agentes con distintos niveles de privilegio podría terminar en fuga de secretos y manipulación del ciclo de vida de pull requests (PR). Aunque Google aplicó medidas correctivas, el reporte muestra un patrón que cualquier equipo que automatice revisiones de código debería tomar en serio.
En este artículo explicamos, en lenguaje claro, qué se observó en el repositorio de agent development kit para Python, cómo se encadenó el abuso y por qué el escenario requiere condiciones adicionales para llegar a la explotación completa.
Cómo funcionaban los agentes y por qué eso importa
La investigación se centró en el repositorio de ADK para Python, donde existen dos clases de agentes automatizados. Por un lado, hay agentes de menor privilegio que se exponen a interacciones de usuarios. Por otro, hay agentes de mayor privilegio reservados para mantenedores y, en consecuencia, con acceso a capacidades restringidas.
El problema emerge cuando un actor malicioso logra que el agente público (de bajo privilegio) dispare acciones que desemboquen en el uso del agente privilegiado. En otras palabras, si un agente menos confiable puede “invocar” indirectamente un flujo diseñado para agentes de confianza, el modelo de seguridad basado en roles puede romperse.
El punto de partida: el triage de pull requests con privilegios
Según el reporte, Pillar Security identificó primero un agente encargado de triage de PR. Lo relevante es que ese agente estaba publicando comentarios con permisos equivalentes a un colaborador de alta capacidad dentro del repositorio.
Ese detalle abrió la puerta a una hipótesis: si el triager con privilegios responde a un formato de instrucción concreto, entonces un atacante podría intentar forzarlo a ejecutar una ruta no prevista. El paso siguiente consistió en encontrar una manera de manipular los comentarios para disparar una invocación más profunda.
Manipulación de prompts: disparo hacia un flujo privilegiado
El investigador halló una forma de introducir en un comentario de PR un comando del tipo @gemini-cli <prompt>. La consecuencia era activar un mecanismo interno, descrito como gemini-invoke, que a su vez conectaba con un workflow con privilegios superiores.
En el proceso inicial, el sistema respondió de una manera que terminó revelando los tools que el agente privilegiado tenía disponibles a través del servidor MCP. Esta parte es clave: no se trataba únicamente de realizar una acción; el hallazgo permitía observar qué capacidades concretas estaban habilitadas.
Fuga de herramientas y alcance del acceso
El análisis concluyó que el bot podía acceder a comandos de bash. Con esa clase de acceso, un investigador podía ejecutar código de forma remota. Además, el reporte indica que esto podía permitir la extracción de un token de GitHub asociado a la actividad del agente.
El riesgo no se limitaba a “romper” una PR aislada. Al contar con el token, el actor podría modificar comentarios, PRs e issues de otras personas que tuvieran relaciones de colaboración. También podía afectar el flujo de trabajo al aprobar o descartar revisiones, y activar revisiones o invocaciones sobre cualquier PR.
Manipular el ciclo de aprobación de PR: qué se podía lograr
El hallazgo también describe un escenario para envenenar el ciclo de aprobación. La idea central consistía en construir una narrativa operativa para que una PR “maliciosa” pareciera haber sido procesada por el sistema de revisión, incluso cuando no lo había sido realmente.
Sin embargo, el reporte aclara un matiz importante: para que una PR maliciosa se integrara finalmente, alguien con el rol adecuado debía aprobar y fusionar el cambio. Ese paso introduce una barrera adicional que, en términos del investigador, dependía de ingeniería social.
El “rastro creíble” que no ocurrió
El investigador describió que el abuso combinaba permisos y acciones encadenadas. En esencia, el atacante editaba el comentario del agente triager, aprovechando una capacidad de escritura sobre issues. Luego, usaba el acceso obtenido (vía la ejecución y extracción del token) para publicar y aprobar como si el bot lo hubiera hecho. Finalmente, cambiaba etiquetas y solicitudes de revisión que caen bajo permisos de modificación de pull requests.
El resultado era un historial consistente y convincente para un revisor humano: “un humano pidió una revisión, el sistema la ejecutó, el sistema aprobó”. Pero ese rastro, recalca el reporte, podía haberse fabricado mediante los pasos encadenados. La verosimilitud del rastro es precisamente lo que vuelve el caso peligroso para procesos donde las personas confían en evidencias automatizadas.
Qué requirió el ataque para funcionar
Para materializar el escenario, el actor debía primero ganarse la confianza como colaborador. Después, necesitaba abrir una primera PR que incluyera código malicioso, dejando que el sistema iniciara el proceso de revisión. Luego, el atacante creaba una segunda PR con instrucciones en forma de prompts orientados a lograr que el agente etiquetara, marcara como revisado y aprobara la PR anterior.
Este diseño exige que el entorno permita interacción con el agente público y que el sistema no separe suficientemente los límites de confianza entre agentes. En el mundo real, no todos los repositorios o configuraciones presentarían exactamente el mismo encadenamiento, pero la lección sobre “transferencia de privilegios” es aplicable.
Respuesta de Google y limitación del caso para bug bounty
Google fue notificado del hallazgo a inicios de junio. De acuerdo con el reporte, la corrección se implementó mediante endurecimiento (hardening). No obstante, Pillar explicó que Google no consideró que el caso alcanzara el umbral para recompensas de bug bounty, en parte porque la explotación completa requería ingeniería social para que el PR malicioso se fusionara.
En otras palabras: el impacto potencial era alto, pero el camino práctico hacia la integración final no era automático; dependía de persuadir o manipular a participantes humanos del proceso.
Una segunda vulnerabilidad: ejecución de código sin interacción
Poco después, Pillar identificó otro problema en el repositorio de ADK. En esta ocasión, el foco estaba en funciones de automatización asociadas a un agente basado en Antigravity-SDK.
El reporte indica que esta segunda debilidad podía conducir a ejecución remota de código sin necesidad de interacción por parte de un mantenedor. Según el artículo, Google arregló la vulnerabilidad hacia finales de julio.
Implicaciones para equipos que automatizan revisiones con IA
Más allá del caso específico, el ataque entre agentes Gemini subraya una preocupación recurrente en sistemas con automatización: cuando existen agentes con niveles de privilegio diferentes, cualquier camino que permita que un agente menos confiable dispare acciones de otro más confiable puede convertirse en un vector de compromiso.
- Control de invocaciones: revisar qué condiciones permiten activar workflows privilegiados desde entradas de menor confianza.
- Segregación de capacidades: evitar que herramientas sensibles queden disponibles bajo contextos de agentes no verificados.
- Validación humana: reforzar revisiones que dependan de señales automatizadas, especialmente cuando el historial puede ser manipulable.
- Registro y trazabilidad: asegurar que los eventos críticos no puedan parecer legítimos si no lo fueron.
Si tu equipo usa agentes de IA para triage o aprobaciones, este tipo de hallazgos es una invitación a replantear supuestos: “si el agente lo hizo, debe ser cierto”. La investigación demuestra que, con los permisos correctos, la automatización puede producir evidencia que no refleja acciones reales.
Conclusión
El reporte de Pillar Security expone cómo un ataque entre agentes Gemini podría encadenar manipulación de prompts, activación de workflows privilegiados y exposición de herramientas, derivando en acceso remoto y posible extracción de credenciales. Aunque para completar la fusión de una PR maliciosa hacía falta ingeniería social, el riesgo operativo seguía siendo significativo: se podía fabricar un rastro convincente de revisión y aprobación.
Con las correcciones aplicadas por Google y una segunda vulnerabilidad ya tratada, el caso sirve como recordatorio: en automatización con IA, la seguridad no solo depende del agente individual, sino del límite entre agentes, del diseño de permisos y de cómo se confía en las señales que produce la plataforma.
