Um agente de IA convenceu outro a executar comandos de hacker — esquema de ataque perigoso encontrado no SDK do Google

No repositório do kit de desenvolvimento Python do Google, o pesquisador Dan Lisichkin, da Pillar Security, descobriu uma vulnerabilidade que permite a um atacante hipotético comprometer software no nível da cadeia de suprimentos ao manipular um agente de IA altamente privilegiado por meio de solicitações maliciosas a um agente de IA público menos privilegiado. O esquema de ataque abusa dos mecanismos de interação entre agentes de IA. No repositório do Google, existem dois agentes: o primeiro, público, analisa as consultas dos usuários e as novas solicitações de merge; o segundo, acessível apenas aos mantenedores do projeto, tem permissões mais amplas. O primeiro pode delegar tarefas ao segundo, e essa transferência é considerada confiável. Para realizar o ataque, o atacante primeiro envia um fragmento de código benigno para ganhar confiança e a capacidade de executar certos processos no nível do agente de IA. Na segunda etapa, ele envia outra solicitação de merge com instruções maliciosas incorporadas na descrição para o agente público. O agente público as interpreta como parte de sua tarefa e chama o agente de IA privilegiado, passando a ele uma mensagem confiável. O segundo agente então ganha a capacidade de realizar ações que um usuário normal nunca poderia executar diretamente. Isso não é uma vulnerabilidade de software no sentido tradicional, mas um problema na cadeia de confiança entre agentes: os mecanismos do GitHub Actions são públicos, e qualquer pessoa pode analisar como eles interagem. O Google, no entanto, recusou-se a pagar ao pesquisador uma recompensa, argumentando que mesmo com um token com permissões de 'pull-requests: write', o código não é incluído automaticamente, mas pela vontade de um mantenedor humano. A empresa reforçou as proteções do fluxo de trabalho e listou o pesquisador como coautor da correção. O pesquisador insiste que o Google fechou apenas uma implementação da vulnerabilidade, não o problema subjacente. Não basta endurecer os fluxos de trabalho ou isolar os agentes de IA uns dos outros: os agentes devem ser identificados e ter conjuntos fixos de permissões, semelhantes ao controle de acesso para humanos. Ele insta a inclusão de agentes de IA nos modelos de ameaça, pois eles são potenciais atacantes nos fluxos de trabalho.