O investigador de segurança Dan Lisichkin, da Pillar Security, fez no repositório do Agent Development Kit da Google algo que não tinha sido demonstrado publicamente até agora: usou um agente de IA para atacar outro.
O cenário é banal, e é justamente isso que o torna interessante. O repositório google/adk-python, que os seus mantenedores anunciam com mais de 90 milhões de descargas, corre agentes sobre as suas próprias pull requests. Um deles é um revisor virado para o público, ao qual a contribuição de qualquer pessoa chega. Funciona com um token de acesso pessoal de colaborador, ou seja, modesto. Outro agente está mais para dentro, com privilégios de mantenedor.
O mecanismo
Uma pull request não é só código. Tem um título, um corpo, um diff e comentários, e tudo isso é texto que um agente lê. Lisichkin colocou uma injeção de prompt nesse texto. O revisor de baixo privilégio leu-o e, em vez de se limitar a rever, agiu de uma forma que acionou o agente de privilégio elevado.
Em rigor, nada estava avariado. Cada agente fez aquilo para que foi construído. O revisor leu entrada não fiável, porque é o seu trabalho. O segundo agente confiou num sinal vindo do interior do repositório, porque o interior é suposto ser seguro. O que ninguém tinha escrito é a fronteira entre os dois, e uma fronteira não escrita não é aplicada.
A Google corrigiu e recusou pagar
É a passagem em que vale a pena parar, porque os dois lados têm um argumento verdadeiro.
A Google resolveu o problema. A Google também recusou o prémio, dizendo que não recompensa relatórios de vulnerabilidade que exijam engenharia social para permitir um comprometimento da cadeia de fornecimento, e sublinhando que um mantenedor tem ainda assim de carregar em "fundir", já que as pull requests não são fundidas automaticamente após a revisão de um bot.
Não é uma fuga. É factualmente exato: a cadeia só se fecha se uma pessoa aceitar uma pull request maliciosa. Muitas escalas de gravidade desvalorizam, com razão, as descobertas que precisam da cooperação de um humano.
A resposta do investigador também está correta, e é sobre conceção mais do que sobre gravidade. A sua posição, nas suas próprias palavras, é que os agentes deveriam ter a sua própria identidade, que determina a que recursos lhes é permitido aceder e de que maneira lhes é permitido interagir com esses recursos. Um agente que pede emprestado o token de uma pessoa herda as permissões de uma pessoa, e nenhuma etapa de revisão compensa isso.
Não é preciso escolher um vencedor. A leitura honesta é que este exploit em concreto precisou de um erro humano, e que a arquitetura que ele expõe não precisará de nenhum para ser um problema da próxima vez.
Porque "ainda é preciso um humano para fundir" vai envelhecer mal
Exigir que um mantenedor funda é uma barreira real hoje. É uma barreira que toda a indústria está neste momento a trabalhar para remover.
O sentido da marcha no desenvolvimento agêntico vai para menos pontos de controlo humanos, não para mais. Cada regra de fusão automática, cada política do tipo "o bot aprovou, portanto entra", cada pipeline em que a saída de um agente alimenta outro agente sem ninguém pelo meio, retira exatamente o passo com que a Google conta. A mitigação é organizacional, e as mitigações organizacionais degradam-se.
O que fazer no seu próprio repositório
Nada disto exige a escala da Google. Se corre agentes nos seus repositórios:
- Dê a cada agente a sua própria identidade. Partilhar um token de acesso pessoal entre uma pessoa e um bot, ou entre dois bots, significa deixar de poder restringir ou revogar seja o que for de forma independente, e deixar de poder dizer, por um registo de auditoria, quem fez o quê.
- Restrinja o token à tarefa. Um revisor precisa de ler um diff e escrever um comentário. Não precisa de acesso de escrita aos ramos.
- Trate tudo o que um agente lê do exterior como portador de instruções. O corpo de uma pull request escrito por um desconhecido merece a mesma desconfiança que um campo de formulário num site público. O nosso guia sobre segurança de agentes de IA cobre o padrão geral.
- Não deixe que a saída de um agente seja o gatilho de confiança de outro. Se o agente B age pela palavra do agente A, então quem controla a entrada de A controla B.
Não confundir com os pacotes litellm
Um incidente distinto toca o mesmo ecossistema e mistura-se muitas vezes com este. Em março de 2026 foram publicadas no PyPI versões maliciosas do litellm, a 1.82.7 e a 1.82.8, através de credenciais de mantenedor comprometidas, numa janela de cerca de três horas. Quem instalasse google-adk com extensões durante essa janela levava-as consigo.
É um comprometimento de dependência clássico: credenciais roubadas, pacote envenenado, janela curta. Não tem nada a ver com agentes que falam uns com os outros. Ambos são incidentes de cadeia de fornecimento, mas as defesas diferem, e tratá-los como uma história única leva a corrigir um e julgar que se cobriu o outro.
O que retirar daqui
A descoberta é modesta no impacto imediato e grande naquilo que sinaliza. Um agente não é uma ferramenta que corre quando se carrega num botão. É um ator que lê, decide e age, e a partir do momento em que tem dois no mesmo repositório com privilégios diferentes, tem uma fronteira de confiança, quer a tenha desenhado quer não.
Dê identidades aos agentes antes de lhes dar permissões.
Fontes
- Investigação da Pillar Security, noticiada pelo The Register, 3 de agosto de 2026.
