Principales destacados
- Investigadores de Pillar Security demostraron un ataque en el que una instrucción maliciosa colocada en una issue pública podía manipular a un agente de IA con pocos privilegios para activar otro agente con permisos mayores.
- El caso expuso una falla importante en el modelo de confianza de las automatizaciones utilizadas en el repositorio del Agent Development Kit, el ADK, para Python, permitiendo llegar a la ejecución de código en un entorno de integración continua.
- Google eliminó tres workflows afectados y reforzó el repositorio, pero consideró que el caso no cumplía los criterios para una recompensa por vulnerabilidad porque el ataque aún dependía de la aprobación de un mantenedor.
La inteligencia artificial está entrando cada vez más profundamente en entornos donde tradicionalmente solo los desarrolladores y sistemas automatizados tenían autoridad. Los agentes ya pueden analizar código, responder a problemas, crear archivos, ejecutar herramientas, revisar cambios e incluso delegar tareas a otros agentes.
Esta evolución trae enormes ganancias de productividad, pero también crea un problema de seguridad que aún se está comprendiendo: ¿qué ocurre cuando un agente controlado por un atacante consigue convencer a otro agente, con más privilegios, de actuar en su lugar?
Fue este escenario el que investigadores de Pillar Security demostraron al analizar los workflows automatizados asociados al repositorio del Agent Development Kit, el ADK, para Python. El estudio describe una cadena de ataque en la que una instrucción insertada en una issue pública podía influir en un agente de triage y hacer que activara un flujo reservado a participantes confiables del proyecto.
El caso es especialmente relevante porque no depende simplemente de que una IA “rompa” sus propias reglas. La técnica explora la forma en que diferentes agentes, cuentas, workflows y permisos están conectados. En otras palabras, la debilidad no estaba en un agente aislado, sino en la confianza existente entre los componentes.
El ADK es un framework de código abierto desarrollado por Google para crear, evaluar e implementar agentes de inteligencia artificial. La documentación oficial destaca precisamente la posibilidad de construir sistemas multiagente, en los que distintos agentes pueden colaborar, delegar tareas y participar en flujos de trabajo más complejos. El framework también ofrece integración con herramientas externas y diferentes entornos de ejecución.
Es precisamente esta capacidad de conectar agentes lo que hace que el episodio sea tan importante para el futuro de la seguridad en IA.
El problema comenzó con una simple interacción pública
El repositorio analizado utilizaba diferentes clases de agentes automatizados con niveles de privilegio distintos.
Por un lado estaba un agente público, activado por interacciones como issues o pull requests. Este componente tenía la función de analizar el contenido recibido y responder a través de la cuenta “adk-bot”.
Por otro lado estaban workflows más sensibles, destinados a tareas que requerían un mayor nivel de confianza. Estos procesos estaban configurados para responder a comandos asociados a propietarios, miembros o colaboradores del proyecto.
La separación parecía crear una barrera de seguridad. Un usuario externo podía interactuar con el agente público, pero no debería poder ejecutar directamente acciones destinadas a los colaboradores.
El problema identificado por Pillar Security estaba en el medio de esta arquitectura.
Según la investigación, un atacante podía insertar una instrucción especialmente preparada en una issue pública. El agente de menor privilegio procesaba ese contenido y podía ser inducido a publicar un mensaje que contuviera el comando necesario para activar un workflow privilegiado.
El detalle decisivo era la identidad utilizada para realizar la acción.
Como el comando aparecía asociado a “adk-bot”, el sistema responsable de la validación podía interpretarlo como una solicitud proveniente de una entidad confiable. El atacante, por lo tanto, no necesitaba obtener directamente el mismo permiso. Bastaba con manipular un componente que ya tenía acceso suficiente para atravesar la siguiente barrera.
Es un concepto que puede parecer extraño para quienes piensan en seguridad de software tradicional. Normalmente, una aplicación verifica quién realiza una solicitud y qué permisos tiene esa identidad. En sistemas agénticos, sin embargo, existe una capa adicional: lo que el agente fue llevado a creer que debía hacer.
Esta diferencia es fundamental.
Un agente puede recibir información externa, interpretarla como una instrucción legítima y transformarla en una acción. Si otro sistema confía en esa acción simplemente porque proviene de una identidad técnicamente autorizada, la cadena de confianza puede ser explotada.
La propia evolución del ADK muestra por qué este problema tiende a ganar importancia. Google promueve el framework como una plataforma capaz de crear arquitecturas en las que agentes especializados trabajan en conjunto y delegan tareas. En una arquitectura de este tipo, la seguridad no puede considerar solo el comportamiento individual de cada agente. Es necesario analizar también lo que ocurre cuando interactúan entre sí.
Una barrera de privilegios terminó convirtiéndose en un puente
El hallazgo de Pillar va más allá de una inyección de prompt tradicional.
La llamada prompt injection ocurre cuando un modelo recibe contenido que incluye instrucciones maliciosas y comienza a seguirlas como si fueran parte legítima de la tarea. Esto puede suceder en textos enviados directamente por el usuario o de forma indirecta, a través de documentos, páginas, comentarios, archivos y otros datos que el agente consulta.
En el caso investigado, el contenido malicioso entraba a través de una issue pública. A partir de ahí, el primer agente funcionaba como una especie de intermediario.
La intención del atacante era hacer que el agente público produjera una acción que normalmente solo realizaría alguien con mayor confianza dentro del proyecto.
Los investigadores también descubrieron que algunas de las protecciones utilizadas en el workflow privilegiado no eran suficientes para impedir la explotación.
Una de estas medidas limitaba los comandos aceptados a instrucciones que comenzaran con herramientas como gh o git. La idea era restringir lo que el agente podía hacer y evitar comandos arbitrarios.
Sin embargo, la seguridad de un sistema no depende solo del nombre del comando ejecutado.
La investigación mostró que operaciones aparentemente permitidas, combinadas con escritura de archivos y rutas configurables relacionadas con los hooks de Git, podían crear una cadena capaz de resultar en ejecución arbitraria de código.
Este es uno de los puntos más importantes del hallazgo. Una lista de comandos permitidos no necesariamente representa una lista de acciones seguras.
Un comando legítimo puede interactuar con archivos, configuraciones o herramientas externas de una forma que produzca un resultado peligroso.
Este tipo de problema ya ha aparecido en otras investigaciones sobre agentes de desarrollo. En julio, la propia Pillar publicó una serie sobre escapes de sandbox en diferentes herramientas de programación basadas en IA. La conclusión general fue que, en algunos casos, el agente no necesitaba romper directamente el aislamiento: bastaba con modificar algo que un componente confiable fuera del sandbox ejecutaría, cargaría o interpretaría posteriormente.
La similitud entre estos casos es importante. El problema no está necesariamente en una herramienta aislada, sino en la cadena de confianza que se forma cuando diferentes componentes automatizados interactúan.
El impacto potencial también aumenta cuando hay credenciales disponibles en el entorno.
Durante la demostración, los investigadores lograron extraer el token de acceso personal utilizado por el bot. También encontraron una clave de cuenta de servicio de Google Cloud disponible en el entorno del workflow, aunque no pudieron determinar completamente el alcance de los permisos asociados a esas credenciales.
Esto no significa que todas esas credenciales pudieran automáticamente dar control total sobre la infraestructura. Pero su presencia muestra por qué el principio de mínimo privilegio es tan importante en entornos con agentes.
Si un agente solo necesita analizar una issue, no debería tener credenciales capaces de modificar código.
Si necesita modificar un archivo específico, no debería tener acceso irrestricto al repositorio.
Y, sobre todo, si un agente consume contenido controlado por usuarios externos, ese contenido no debería poder transformarlo en una autoridad capaz de activar automáticamente otro componente privilegiado.
Google eliminó tres workflows y el caso enciende una alerta mayor
Tras el hallazgo, Google eliminó los workflows issue-analyze.yml, issue-fix.yml y pr-analyze.yml del repositorio del ADK. Según la información presentada en el caso, los cambios fueron registrados en un commit fechado el 9 de junio de 2026, mientras que la corrección fue confirmada por la empresa el 21 de julio.
Sin embargo, la empresa no clasificó el episodio como elegible para una recompensa de bug bounty. La justificación fue que el ataque aún requería una etapa adicional que involucraba a un mantenedor, ya que sería necesario que un pull request malicioso fuera incorporado.
Esta distinción es importante. Una vulnerabilidad puede ser técnicamente interesante y demostrar una cadena de ataque relevante sin necesariamente cumplir todos los criterios de un programa de recompensas.
Para la seguridad de agentes, sin embargo, la discusión va mucho más allá del valor de una recompensa.
El caso muestra que los sistemas de IA pueden crear nuevas formas de movimiento dentro de una infraestructura. En un entorno tradicional, un atacante sin privilegios suficientes necesitaría encontrar una falla técnica para elevar su autorización. En un entorno agéntico, existe una posibilidad adicional: manipular un componente autorizado para que ejecute la siguiente etapa.
Es una especie de movimiento lateral basado en la confianza.
El atacante no necesita ser reconocido como administrador. Puede intentar convencer a una entidad que ya tiene autoridad para actuar en su lugar.
Este cambio también aparece en trabajos más amplios sobre seguridad de sistemas agénticos. La Cloud Security Alliance afirma que las arquitecturas con agentes requieren especial atención a la comunicación entre agentes, la confianza, el uso de herramientas, el contexto y la orquestación. El grupo defiende un enfoque de seguridad basado en verificación continua y principios cercanos al Zero Trust, en lugar de asumir que ciertos componentes son confiables solo por formar parte de la arquitectura.
El framework MAESTRO, también discutido por la Cloud Security Alliance, incluye entre los riesgos de sistemas multiagente escenarios de escalada de privilegios, movimiento lateral, filtración de datos y ataques que atraviesan diferentes capas de la arquitectura.
Esto ayuda a situar el episodio de Google en una perspectiva más amplia.
La cuestión no es simplemente “una IA fue engañada”.
La cuestión es que la IA estaba conectada a herramientas reales, identidades reales y permisos reales.
Cuando un chatbot responde incorrectamente, el impacto puede ser solo una respuesta equivocada. Cuando un agente tiene acceso a un repositorio, credenciales y capacidad de ejecutar workflows, el mismo tipo de manipulación puede convertirse en una acción operativa.
El agente no necesita ser el objetivo final
Uno de los aspectos más interesantes de la investigación es que el primer agente atacado no necesitaba tener todos los permisos necesarios para comprometer el sistema.
Solo necesitaba tener la capacidad suficiente para comunicarse con otro componente más poderoso.
Esta idea cambia la forma en que los equipos de seguridad deben evaluar a los agentes.
En lugar de preguntar solo “¿qué puede hacer este agente?”, también es necesario preguntar:
“¿Quién confía en lo que este agente produce?”
Y además:
“¿Qué ocurre si el contenido que recibió fue controlado por un atacante?”
Esta segunda pregunta es particularmente importante porque los agentes están diseñados para consumir grandes cantidades de información. Issues, pull requests, comentarios, documentación, código, archivos y resultados de herramientas pueden entrar en el contexto del modelo.
En muchos sistemas, estos datos se tratan como contenido.
Para un modelo de lenguaje, sin embargo, contenido e instrucción pueden aparecer en el mismo flujo de contexto. Es precisamente ahí donde la inyección de prompt se vuelve peligrosa.
Investigaciones recientes también muestran que este problema no se limita a un solo producto. Pillar, por ejemplo, ya ha documentado vulnerabilidades en Gemini CLI y otros agentes de desarrollo, mientras que trabajos académicos recientes investigan la capacidad de los agentes de IA para transformar vulnerabilidades existentes en exploits funcionales. Un estudio llamado ExploitGym evaluó cientos de escenarios reales y encontró que los modelos de frontera ya pueden explotar una parte no trivial de las vulnerabilidades probadas, aunque la tarea sigue siendo difícil.
Esto crea una combinación particularmente delicada: los agentes están mejorando en la ejecución de tareas complejas al mismo tiempo que reciben acceso a entornos cada vez más poderosos.
La seguridad, por lo tanto, debe evolucionar junto con ellos.
Lo que las empresas deben cambiar
La recomendación central de Pillar Security es relativamente simple de explicar: cada agente debe tener una identidad propia y permisos restringidos al mínimo necesario.
Pero en la práctica, esto implica un cambio significativo en la arquitectura.
Un agente que lee contenido no confiable debe ser tratado como un componente potencialmente manipulable. Su resultado no debería recibir automáticamente el mismo nivel de confianza que una decisión humana.
Cuando un agente necesita activar otro con privilegios superiores, debe existir una barrera independiente del modelo. Esa barrera debe verificar la autorización de forma que una simple instrucción insertada en el contexto no pueda falsificarla.
Otra medida importante es mapear el camino completo de los permisos.
No basta con saber que el agente A puede leer issues y el agente B puede modificar código. Es necesario determinar si A puede, directa o indirectamente, hacer que B ejecute una acción.
Este tipo de análisis es especialmente relevante en pipelines de integración y entrega continua, donde pequeños permisos pueden transformarse en grandes consecuencias.
El propio Google continúa ampliando el uso de agentes y arquitecturas multiagente. En su documentación actual, el ADK se presenta como una estructura capaz de ejecutar desde asistentes hasta workflows empresariales y sistemas sofisticados en los que agentes especializados colaboran y delegan tareas.
Esto significa que el problema observado en el repositorio no es un argumento contra los agentes de IA.
Es un argumento a favor de una arquitectura más cuidadosa.
Cuanta más autonomía recibe un agente, más importante se vuelve separar capacidad de confianza.
Un agente puede ser muy bueno interpretando lenguaje, escribiendo código o decidiendo qué herramienta utilizar. Eso no significa que deba estar autorizado a conceder permisos, aprobar cambios de seguridad o representar automáticamente una identidad humana.
La lección más importante que deja el episodio es precisamente esta: el aislamiento entre agentes no es suficiente cuando existe un puente de confianza entre ellos.
Si un agente con bajo privilegio puede influir en otro con mayor acceso, ambos deben ser analizados como parte de una misma superficie de ataque.
Y este es un cambio profundo en el modelo tradicional de seguridad.
Antes de la era de los agentes, una aplicación normalmente recibía una solicitud, verificaba la identidad y ejecutaba una operación. Ahora, una solicitud puede pasar por una secuencia de agentes, cada uno interpretando el contexto, tomando decisiones y activando diferentes herramientas.
En cada una de estas etapas existe la posibilidad de manipulación.
Por eso, la seguridad de los sistemas agénticos no puede depender solo de filtros de prompt, listas de comandos o sandboxes aislados. Es necesario combinar identidad fuerte, mínimo privilegio, validación independiente, controles de ejecución, monitoreo y revisión de las relaciones de confianza entre agentes.
El episodio del ADK muestra por qué esta discusión ha dejado de ser teórica.
La IA ya no solo está produciendo texto.
Está comenzando a operar infraestructura.
Y cuando una inteligencia artificial puede pedirle a otra que haga algo para lo que ella misma no tiene autorización, la pregunta más importante deja de ser si un agente es seguro de forma aislada.
La pregunta pasa a ser: ¿hasta dónde puede llegar la cadena de confianza entre estos agentes?
