Google eliminó tres workflows ADK del repositorio de Python de su Agent Development Kit (ADK). El motivo no fue un fallo “en el paquete” distribuido, sino un problema en la automatización del repositorio que podía ser explotado a través de un asunto público en GitHub.
De acuerdo con la investigación de Pillar Security, una persona podía usar inyección de prompts para hacer que un agente de “triage” terminara activando un agente de “arreglo de código” con permisos privilegiados. Además, el equipo demostró ejecución de código en el entorno de integración continua (CI) y la exfiltración de un token con alcance para automatizaciones.
Qué workflows ADK se retiraron y por qué
La retirada afectó a tres archivos de automatización. En concreto, se eliminaron los workflows relacionados con:
- issue-analyze.yml: se ejecutaba automáticamente cuando se creaba un issue.
- issue-fix.yml: reaccionaba a comentarios con un comando específico (por ejemplo, /adk-issue-fix).
- pr-analyze.yml: vinculado al análisis de pull requests.
Google señaló que estos flujos procesaban contenido no confiable de issues y pull requests utilizando credenciales amplias a nivel de repositorio. Tras el hallazgo, publicó un commit de eliminación (con metadatos fechados alrededor del 9 de junio de 2026) y Pillar indicó que verificó que ya no estaban presentes el 2 de julio.
El punto de partida: un issue público
El camino de ataque comenzó en el workflow issue-analyze.yml. Este se disparaba al abrir un issue y autenticaba el proceso usando credenciales de Google, incluyendo una clave asociada a una cuenta de servicio (ADK_GCP_SA_KEY), además de un identificador para el agente de triage (ADK_TRIAGE_AGENT) y una clave de Google (GOOGLE_API_KEY).
Luego, el agente de codificación de Antigravity generaba un análisis y publicaba ese análisis como comentario, usando la cuenta/bot configurada dentro del repositorio.
La inyección de prompts que saltó la compuerta
El núcleo del problema estaba en cómo se validaba la orden para ejecutar el flujo privilegiado. Pillar explicó que el agente público podía ser “manipulado” mediante prompt injection para que publicara el comando /adk-issue-fix como si fuera adk-bot.
En el workflow issue-fix.yml, la ejecución restringida se basaba en quién publicaba el comando: owner, member o collaborator. El detalle crítico es que el gate comprobaba la identidad que aparecía como origen del comando, no si un tercero había manipulado previamente el texto para que la cuenta “confiable” generara esa instrucción.
Así, la identidad confiable del bot actuó como “puente de autorización”: el sistema interpretaba que la solicitud provenía de una parte permitida, aunque en realidad la señal había sido inducida por el atacante.
Qué ocurrió dentro del entorno de CI
Una vez superada la compuerta, el workflow privilegiado permitió acciones más peligrosas. Pillar reportó:
- Ejecución arbitraria de código en el runner de CI.
- Exfiltración del token (PAT) personal de acceso asociado al bot.
El trabajo también indicó que el job privilegiado tenía información adicional sensible, como una clave de Google API y credenciales de cuenta de servicio de Google Cloud.
Importante: los investigadores declararon que sus pruebas de concepto no demostraban explotación activa “en el mundo real” ni una versión de ADK realmente comprometida. Es decir, la evidencia pública apunta al entorno y la ruta de automatización, no necesariamente a un ataque ya en producción.
Por qué el acceso privilegiado era más amplio de lo esperado
El informe remarca que el workflow privilegiado declaraba permisos de escritura sobre issues, contenidos del repositorio y pull requests. Sin embargo, esas configuraciones se aplicaban a GITHUB_TOKEN generado por GitHub, mientras que el trabajo usaba realmente un token PAT del agente (ADK_TRIAGE_AGENT PAT) en su ejecución.
En otras palabras: incluso si una parte del “modelo de permisos” parecía controlado, el flujo efectivamente operaba con credenciales adicionales en el entorno del agente.
Sobre el PAT, Pillar indicó que los alcances exactos no estaban publicados. Aun así, describieron que el job:
- Hacía checkout del repositorio usando el PAT.
- Se autenticaba contra Google Cloud.
- Ejecutaba el agente con el PAT y la clave API en variables de entorno.
La automatización estaba diseñada para editar código, crear un fork de adk-bot, empujar cambios y abrir una pull request. De hecho, el reporte menciona que existe un historial observable: una pull request generada el 4 de junio sugiere que la automatización funcionaba en el repositorio.
La “allowlist” de comandos no cerró del todo la puerta
Según Pillar, el runner rechazaba metacaracteres de shell y permitía solo comandos cuyo primer token fuera gh o git. Pero el script habilitó una configuración que, según la documentación del SDK de Antigravity citada por el equipo, activaba todas las herramientas, incluidas capacidades de escritura.
Ese detalle abrió una vía para que el agente escribiera un payload y lograra ejecución a través de un “hook” personalizado en el sistema de Git.
La documentación de Git respalda la idea: los hooks son programas ejecutables, y existe la opción core.hooksPath para redirigir Git hacia otro directorio. Con una allowlist limitada al “formato” del comando, todavía era posible llegar a ejecución indirecta mediante escritura y el mecanismo de hooks.
Alcance real de las credenciales: lo que se sabe y lo que no
Pillar señaló que los artefactos públicos no prueban si el PAT podía empujar directamente a la rama principal. Además, el equipo afirmó que Google le indicó que la cuenta de servicio tenía acceso a Vertex AI en un proyecto dedicado de gestión de GitHub, aunque no se revelaron permisos más amplios.
En resumen: el reporte describe con claridad la ejecución del runner y la exposición de credenciales en el entorno mostrado, pero el registro público no confirma el “downstream” exacto, ni a qué repositorios o servicios llegaron posteriormente esas credenciales.
Estado de respuesta y verificación
En el proceso de seguimiento, The Hacker News contactó tanto a Google como a Pillar Security. Se preguntó a Google por el alcance de los tokens del bot, permisos de la cuenta de servicio y evidencias de explotación; y a Pillar por el entorno de prueba de concepto y el acceso a credenciales. En el momento de la redacción, las respuestas estaban pendientes.
También se realizó una comprobación posterior: una búsqueda el 4 de agosto de 2026 encontró que los nombres de archivo eliminados ya no aparecían en el directorio de workflows en la rama principal actual.
Qué lecciones deja el caso de workflows ADK
Más allá de que Google haya retirado los workflows ADK, el caso es una señal clara sobre automatización con agentes. Pillar recomienda, para repositorios similares, separar identidades de bots, restringir el alcance de tokens y herramientas, y diseñar una forma de autorización en la que texto no confiable no pueda generar por sí mismo la “señal” necesaria para ejecutar acciones privilegiadas.
En la práctica, el error no fue solo “dar permisos”, sino asumir que una compuerta basada en quién escribe un comando sería suficiente, cuando el atacante podía inducir que la identidad confiable emitiera esa instrucción.
Conclusión
Con la eliminación de tres flujos, Google buscó cortar una ruta que permitía que una manipulación en un issue público terminara activando un agente con capacidades privilegiadas. La investigación de Pillar Security muestra cómo la combinación de inyección de prompts, validación insuficiente de autorización y credenciales potentes en automatizaciones puede desembocar en ejecución en CI y filtración de tokens.
Si trabajas con agentes y pipelines en GitHub, este incidente es una llamada a revisar la arquitectura de permisos, la separación de identidades y cómo se validan señales de autorización cuando interviene entrada no confiable.
Fuente: https://thehackernews.com/2026/08/google-deletes-3-adk-ai-workflows-after.html
