Un agente de IA convenció a otro para ejecutar comandos de hacker — esquema de ataque peligroso hallado en el SDK de Google

En el repositorio del kit de desarrollo de Python de Google, el investigador Dan Lisichkin, de Pillar Security, descubrió una vulnerabilidad que permite a un atacante hipotético comprometer el software a nivel de la cadena de suministro manipulando a un agente de IA altamente privilegiado mediante solicitudes maliciosas a un agente de IA público con menos privilegios. El esquema de ataque abusa de los mecanismos de interacción entre agentes de IA. En el repositorio de Google hay dos agentes: el primero, público, analiza las consultas de los usuarios y las nuevas solicitudes de fusión; el segundo, accesible solo para los responsables del proyecto, tiene permisos más amplios. El primero puede delegar tareas al segundo, y esta transferencia se considera confiable. Para llevar a cabo el ataque, el atacante primero envía un fragmento de código benigno para ganarse la confianza y la capacidad de ejecutar ciertos procesos a nivel del agente de IA. En la segunda etapa, envía otra solicitud de fusión con instrucciones maliciosas incrustadas en la descripción para el agente público. El agente público las interpreta como parte de su tarea y llama al agente de IA privilegiado, pasándole un mensaje confiable. El segundo agente adquiere entonces la capacidad de realizar acciones que un usuario normal nunca podría ejecutar directamente. Esto no es una vulnerabilidad de software en el sentido tradicional, sino un problema de la cadena de confianza entre agentes: los mecanismos de GitHub Actions son públicos y cualquiera puede analizar cómo interactúan. Sin embargo, Google se negó a pagar al investigador una recompensa, argumentando que incluso con un token con permisos de 'pull-requests: write', el código no se incluye automáticamente, sino por la voluntad de un responsable humano. La empresa reforzó las protecciones de flujo de trabajo y enumeró al investigador como coautor de la corrección. El investigador insiste en que Google cerró solo una implementación de la vulnerabilidad, no el problema subyacente. No basta con endurecer los flujos de trabajo o aislar a los agentes de IA entre sí: los agentes deben identificarse y tener conjuntos fijos de permisos, similares al control de acceso para humanos. Insta a incluir a los agentes de IA en los modelos de amenazas, ya que son posibles atacantes en los flujos de trabajo.