El investigador de seguridad Dan Lisichkin, de Pillar Security, hizo en el repositorio del Agent Development Kit de Google algo que no se había demostrado públicamente hasta ahora: usó un agente de IA para atacar a otro.
El escenario es corriente, y eso es justo lo que lo hace interesante. El repositorio google/adk-python, que sus mantenedores declaran con más de 90 millones de descargas, ejecuta agentes sobre sus propias pull requests. Uno de ellos es un revisor de cara al público, al que puede llegar la contribución de cualquiera. Funciona con un token de acceso personal de colaborador, es decir, modesto. Otro agente está más adentro, con privilegios de mantenedor.
El mecanismo
Una pull request no es solo código. Tiene un título, un cuerpo, un diff y comentarios, y todo eso es texto que un agente lee. Lisichkin colocó una inyección de prompt en ese texto. El revisor de bajo privilegio lo leyó y, en lugar de limitarse a revisar, actuó de una manera que activó al agente de privilegio alto.
En sentido estricto no había nada roto. Cada agente hizo aquello para lo que fue construido. El revisor leyó una entrada no fiable, porque ese es su trabajo. El segundo agente confió en una señal procedente del interior del repositorio, porque se supone que el interior es seguro. Lo que nadie había escrito es la frontera entre ambos, y una frontera no escrita no se aplica.
Google lo parcheó y se negó a pagar
Este es el punto en el que vale la pena detenerse, porque los dos bandos tienen un argumento real.
Google corrigió el problema. Google también rechazó la recompensa, diciendo que no premia los informes de vulnerabilidad que necesitan ingeniería social para permitir una compromisión de la cadena de suministro, y subrayando que un mantenedor todavía tiene que pulsar "fusionar", ya que las pull requests no se fusionan automáticamente tras una revisión de un bot.
No es una evasiva. Es exacto de hecho: la cadena solo se cierra si un humano acepta una pull request maliciosa. Muchas escalas de gravedad rebajan, con razón, los hallazgos que necesitan la cooperación de una persona.
La réplica del investigador también es correcta, y va de diseño más que de gravedad. Su postura, en sus propias palabras, es que los agentes deberían tener su propia identidad, que determine a qué recursos se les permite acceder y de qué manera se les permite interactuar con esos recursos. Un agente que toma prestado el token de un humano hereda los permisos de un humano, y ningún paso de revisión compensa eso.
No hace falta elegir un ganador. La lectura honesta es que este exploit concreto necesitó un error humano, y que la arquitectura que deja al descubierto no lo necesitará para ser un problema la próxima vez.
Por qué "un humano todavía tiene que fusionar" envejecerá mal
Exigir que un mantenedor fusione es una barrera real hoy. Es una barrera que toda la industria está trabajando ahora mismo por eliminar.
El sentido de la marcha en el desarrollo agéntico va hacia menos puntos de control humanos, no hacia más. Cada regla de fusión automática, cada política del tipo "el bot lo aprobó, así que entra", cada tubería en la que la salida de un agente alimenta a otro agente sin nadie en medio, elimina justo el paso con el que Google cuenta. La mitigación es organizativa, y las mitigaciones organizativas se degradan.
Qué hacer en tu propio repositorio
Nada de esto exige el tamaño de Google. Si ejecutas agentes en tus repositorios:
- Da a cada agente su propia identidad. Compartir un token de acceso personal entre un humano y un bot, o entre dos bots, significa que ya no puedes acotar ni revocar nada de forma independiente, ni saber por un registro de auditoría quién hizo qué.
- Acota el token a la tarea. Un revisor necesita leer un diff y escribir un comentario. No necesita acceso de escritura a las ramas.
- Trata todo lo que un agente lee desde fuera como portador de instrucciones. El cuerpo de una pull request escrito por un desconocido merece la misma desconfianza que un campo de formulario en un sitio público. Nuestra guía sobre seguridad de agentes de IA cubre el patrón general.
- No dejes que la salida de un agente sea el disparador de confianza de otro. Si el agente B actúa por la palabra del agente A, entonces quien controla la entrada de A controla a B.
No lo confundas con los paquetes de litellm
Un incidente distinto toca el mismo ecosistema y se mezcla a menudo con este. En marzo de 2026 se publicaron en PyPI versiones maliciosas de litellm, la 1.82.7 y la 1.82.8, mediante credenciales de mantenedor comprometidas, en una ventana de unas tres horas. Quien instalara google-adk con extensiones durante esa ventana se las llevaba.
Es una compromisión de dependencia clásica: credenciales robadas, paquete envenenado, ventana corta. No tiene nada que ver con agentes que se hablan entre sí. Ambos son incidentes de cadena de suministro, pero las defensas difieren, y tratarlos como una sola historia lleva a corregir uno creyendo haber cubierto el otro.
Lo que hay que retener
El hallazgo es modesto en impacto inmediato y grande en lo que señala. Un agente no es una herramienta que se ejecuta cuando pulsas un botón. Es un actor que lee, decide y actúa, y en cuanto tienes dos en el mismo repositorio con privilegios distintos, tienes una frontera de confianza, la hayas diseñado o no.
Da identidades a los agentes antes de darles permisos.
Fuentes
- Investigación de Pillar Security, informada por The Register, 3 de agosto de 2026.
