Principais destaques
- Pesquisadores da Pillar Security demonstraram um ataque em que uma instrução maliciosa colocada em uma issue pública poderia manipular um agente de IA com poucos privilégios para acionar outro agente com permissões maiores.
- O caso expôs uma falha importante no modelo de confiança de automações usadas no repositório do Agent Development Kit, o ADK, para Python, permitindo chegar à execução de código em um ambiente de integração contínua.
- O Google removeu três workflows afetados e reforçou o repositório, mas considerou que o caso não atendia aos critérios para uma recompensa por vulnerabilidade porque o ataque ainda dependia da aprovação de um mantenedor.
A inteligência artificial está entrando cada vez mais fundo nos ambientes onde tradicionalmente apenas desenvolvedores e sistemas automatizados tinham autoridade. Agentes já conseguem analisar código, responder a problemas, criar arquivos, executar ferramentas, revisar alterações e até delegar tarefas para outros agentes.
Essa evolução traz ganhos enormes de produtividade, mas também cria um problema de segurança que ainda está sendo compreendido: o que acontece quando um agente controlado por um atacante consegue convencer outro agente, mais privilegiado, a agir em seu lugar?
Foi esse cenário que pesquisadores da Pillar Security demonstraram ao analisar os workflows automatizados associados ao repositório do Agent Development Kit, o ADK, para Python. O estudo descreve uma cadeia de ataque na qual uma instrução inserida em uma issue pública poderia influenciar um agente de triagem e fazer com que ele acionasse um fluxo reservado a participantes confiáveis do projeto.
O caso é especialmente relevante porque não depende simplesmente de uma IA “quebrar” suas próprias regras. A técnica explora a maneira como diferentes agentes, contas, workflows e permissões foram conectados. Em outras palavras, a fraqueza estava menos em um agente isolado e mais na confiança existente entre os componentes.
O ADK é um framework de código aberto desenvolvido pelo Google para criar, avaliar e implantar agentes de inteligência artificial. A documentação oficial destaca justamente a possibilidade de construir sistemas multiagentes, nos quais diferentes agentes podem colaborar, delegar tarefas e participar de fluxos de trabalho mais complexos. O framework também oferece integração com ferramentas externas e diferentes ambientes de execução.
É justamente essa capacidade de conectar agentes que torna o episódio tão importante para o futuro da segurança de IA.
O problema começou com uma simples interação pública
O repositório analisado utilizava diferentes classes de agentes automatizados com níveis distintos de privilégio.
De um lado estava um agente público, acionado por interações como issues ou pull requests. Esse componente tinha a função de analisar o conteúdo recebido e responder por meio da conta “adk-bot”.
Do outro lado estavam workflows mais sensíveis, destinados a tarefas que exigiam um nível maior de confiança. Esses processos eram configurados para responder a comandos associados a proprietários, membros ou colaboradores do projeto.
A separação parecia criar uma barreira de segurança. Um usuário externo poderia conversar com o agente público, mas não deveria conseguir executar diretamente ações destinadas aos colaboradores.
O problema identificado pela Pillar Security estava no meio dessa arquitetura.
Segundo a pesquisa, um atacante poderia inserir uma instrução especialmente preparada em uma issue pública. O agente de menor privilégio processaria aquele conteúdo e poderia ser induzido a publicar uma mensagem contendo o comando necessário para ativar um workflow privilegiado.
O detalhe decisivo era a identidade utilizada para realizar a ação.
Como o comando aparecia associado ao “adk-bot”, o sistema responsável pela validação poderia interpretá-lo como uma solicitação proveniente de uma entidade confiável. O atacante, portanto, não precisava obter diretamente a mesma permissão. Bastava manipular um componente que já possuía acesso suficiente para atravessar a barreira seguinte.
É um conceito que pode parecer estranho para quem pensa em segurança de software tradicional. Normalmente, uma aplicação verifica quem está fazendo uma solicitação e quais permissões essa identidade possui. Em sistemas agênticos, porém, existe uma camada adicional: o que o agente foi levado a acreditar que deveria fazer.
Essa diferença é fundamental.
Um agente pode receber uma informação externa, interpretá-la como uma instrução legítima e transformá-la em uma ação. Se outro sistema confiar nessa ação simplesmente porque ela veio de uma identidade tecnicamente autorizada, a cadeia de confiança pode ser explorada.
A própria evolução do ADK mostra por que esse problema tende a ganhar importância. O Google promove o framework como uma plataforma capaz de criar arquiteturas em que agentes especializados trabalham em conjunto e delegam tarefas. Em uma arquitetura desse tipo, a segurança não pode considerar apenas o comportamento individual de cada agente. É necessário analisar também o que acontece quando eles conversam entre si.
Uma barreira de privilégios acabou virando uma ponte
A descoberta da Pillar vai além de uma tradicional injeção de prompt.
A chamada prompt injection acontece quando um modelo recebe conteúdo que contém instruções maliciosas e passa a seguir essas instruções como se fossem parte legítima da tarefa. Isso pode acontecer em textos enviados diretamente pelo usuário ou de maneira indireta, por meio de documentos, páginas, comentários, arquivos e outros dados que o agente consulta.
No caso investigado, o conteúdo malicioso entrava por uma issue pública. A partir dali, o primeiro agente funcionava como uma espécie de intermediário.
A intenção do atacante era fazer o agente público produzir uma ação que normalmente seria realizada apenas por alguém com mais confiança dentro do projeto.
Os pesquisadores também descobriram que algumas das proteções utilizadas no workflow privilegiado não eram suficientes para impedir a exploração.
Uma dessas medidas limitava os comandos aceitos a instruções que começassem com ferramentas como gh ou git. A ideia era restringir o que o agente poderia fazer e evitar comandos arbitrários.
Entretanto, a segurança de um sistema não depende apenas do nome do comando executado.
A pesquisa mostrou que operações aparentemente permitidas, combinadas com gravação de arquivos e caminhos configuráveis relacionados aos hooks do Git, poderiam criar uma cadeia capaz de resultar em execução arbitrária de código.
Esse é um dos pontos mais importantes da descoberta. Uma lista de comandos permitidos não necessariamente representa uma lista de ações seguras.
Um comando legítimo pode interagir com arquivos, configurações ou ferramentas externas de uma maneira que produza um resultado perigoso.
Esse tipo de problema já apareceu em outras pesquisas envolvendo agentes de desenvolvimento. Em julho, a própria Pillar publicou uma série sobre escapes de sandbox em diferentes ferramentas de programação baseadas em IA. A conclusão geral foi que, em alguns casos, o agente não precisava romper diretamente o isolamento: bastava modificar algo que um componente confiável fora do sandbox posteriormente executasse, carregasse ou interpretasse.
A semelhança entre esses casos é importante. O problema não está necessariamente em uma ferramenta isolada, mas na cadeia de confiança formada quando diferentes componentes automatizados interagem.
O impacto potencial também aumenta quando credenciais estão disponíveis no ambiente.
Durante a demonstração, os pesquisadores conseguiram extrair o token de acesso pessoal utilizado pelo bot. Eles também encontraram uma chave de conta de serviço do Google Cloud disponível no ambiente do workflow, embora não tenham conseguido determinar completamente o alcance das permissões associadas às credenciais.
Isso não significa que todas essas credenciais poderiam automaticamente fornecer controle total sobre a infraestrutura. Mas a presença delas mostra por que o princípio do menor privilégio é tão importante em ambientes com agentes.
Se um agente precisa apenas analisar uma issue, ele não deveria possuir credenciais capazes de alterar código.
Se precisa modificar um arquivo específico, não deveria ter acesso irrestrito ao repositório.
E, principalmente, se um agente consome conteúdo controlado por usuários externos, esse conteúdo não deveria conseguir transformá-lo em uma autoridade capaz de acionar automaticamente outro componente privilegiado.
Google removeu três workflows e o caso acende um alerta maior
Após a descoberta, o Google removeu os workflows issue-analyze.yml, issue-fix.yml e pr-analyze.yml do repositório do ADK. De acordo com as informações apresentadas no caso, as alterações foram registradas em um commit datado de 9 de junho de 2026, enquanto a correção foi confirmada pela empresa em 21 de julho.
A empresa, entretanto, não classificou o episódio como elegível para uma recompensa de bug bounty. A justificativa foi que o ataque ainda exigia uma etapa adicional envolvendo um mantenedor, já que seria necessário que um pull request malicioso fosse incorporado.
Essa distinção é importante. Uma vulnerabilidade pode ser tecnicamente interessante e demonstrar uma cadeia de ataque relevante sem necessariamente cumprir todos os critérios de um programa de recompensa.
Para a segurança de agentes, contudo, a discussão vai muito além do valor de uma recompensa.
O caso mostra que sistemas de IA podem criar novas formas de movimentação dentro de uma infraestrutura. Em um ambiente tradicional, um atacante que não possui privilégios suficientes precisaria procurar uma falha técnica para elevar sua autorização. Em um ambiente agêntico, existe uma possibilidade adicional: manipular um componente autorizado para que ele próprio execute a próxima etapa.
É uma espécie de movimento lateral baseado em confiança.
O atacante não precisa necessariamente ser reconhecido como administrador. Ele pode tentar convencer uma entidade que já possui autoridade a agir por ele.
Essa mudança também aparece em trabalhos mais amplos sobre segurança de sistemas agênticos. A Cloud Security Alliance afirma que arquiteturas com agentes exigem atenção especial para comunicação entre agentes, confiança, uso de ferramentas, contexto e orquestração. O grupo defende uma abordagem de segurança baseada em verificação contínua e princípios próximos do Zero Trust, em vez de assumir que determinados componentes são confiáveis simplesmente por fazerem parte da arquitetura.
O framework MAESTRO, também discutido pela Cloud Security Alliance, coloca entre os riscos de sistemas multiagentes justamente cenários de escalada de privilégios, movimentação lateral, vazamento de dados e ataques que atravessam diferentes camadas da arquitetura.
Isso ajuda a colocar o episódio do Google em uma perspectiva maior.
A questão não é simplesmente “uma IA foi enganada”.
A questão é que a IA estava conectada a ferramentas reais, identidades reais e permissões reais.
Quando um chatbot responde a uma pergunta errada, o impacto pode ser apenas uma resposta incorreta. Quando um agente tem acesso a um repositório, credenciais e capacidade de executar workflows, o mesmo tipo de manipulação pode se transformar em uma ação operacional.
O agente não precisa ser o alvo final
Um dos aspectos mais interessantes da pesquisa é que o primeiro agente atacado não precisava possuir todas as permissões necessárias para comprometer o sistema.
Ele só precisava ter capacidade suficiente para conversar com outro componente mais poderoso.
Essa ideia muda a maneira como equipes de segurança precisam avaliar agentes.
Em vez de perguntar apenas “o que este agente pode fazer?”, também é necessário perguntar:
“Quem confia no que este agente produz?”
E ainda:
“O que acontece se o conteúdo que ele recebeu for controlado por um atacante?”
Esse segundo questionamento é particularmente importante porque agentes são construídos para consumir grandes quantidades de informação. Issues, pull requests, comentários, documentação, código, arquivos e resultados de ferramentas podem entrar no contexto do modelo.
Em muitos sistemas, esses dados são tratados como conteúdo.
Para um modelo de linguagem, porém, conteúdo e instrução podem aparecer no mesmo fluxo de contexto. É justamente aí que a injeção de prompt se torna perigosa.
Pesquisas recentes também mostram que esse problema não está limitado a um único produto. A Pillar, por exemplo, já documentou vulnerabilidades envolvendo o Gemini CLI e outros agentes de desenvolvimento, enquanto trabalhos acadêmicos recentes investigam a capacidade de agentes de IA transformarem vulnerabilidades existentes em exploits funcionais. Um estudo chamado ExploitGym avaliou centenas de cenários reais e encontrou que modelos de fronteira já conseguem explorar uma parcela não trivial das vulnerabilidades testadas, embora a tarefa continue sendo difícil.
Isso cria uma combinação particularmente delicada: agentes estão ficando melhores em executar tarefas complexas ao mesmo tempo em que recebem acesso a ambientes cada vez mais poderosos.
A segurança, portanto, precisa evoluir junto.
O que as empresas precisam mudar
A recomendação central da Pillar Security é relativamente simples de explicar: cada agente deve possuir uma identidade própria e permissões restritas ao mínimo necessário.
Mas, na prática, isso significa uma mudança significativa na arquitetura.
Um agente que lê conteúdo não confiável deve ser tratado como um componente potencialmente manipulável. Seu resultado não deveria automaticamente receber o mesmo nível de confiança de uma decisão humana.
Quando um agente precisa acionar outro com privilégios superiores, deve existir uma barreira independente do modelo. Essa barreira precisa verificar a autorização de forma que uma simples instrução inserida no contexto não seja capaz de falsificá-la.
Outra medida importante é mapear o caminho completo das permissões.
Não basta saber que o agente A pode ler issues e o agente B pode modificar código. É necessário descobrir se A pode, direta ou indiretamente, fazer B executar uma ação.
Esse tipo de análise é particularmente relevante em pipelines de integração e entrega contínuas, nos quais pequenas permissões podem se transformar em grandes consequências.
O próprio Google continua expandindo o uso de agentes e de arquiteturas multiagentes. Em sua documentação atual, o ADK é apresentado como uma estrutura capaz de executar desde assistentes até workflows empresariais e sistemas sofisticados em que agentes especializados colaboram e delegam tarefas.
Isso significa que o problema observado no repositório não é um argumento contra agentes de IA.
É um argumento a favor de uma arquitetura mais cuidadosa.
Quanto mais autonomia um agente recebe, mais importante se torna separar capacidade de confiança.
Um agente pode ser muito bom em interpretar linguagem, escrever código ou decidir qual ferramenta utilizar. Isso não significa que ele deva ser autorizado a conceder permissões, aprovar mudanças de segurança ou representar automaticamente uma identidade humana.
A lição mais importante deixada pelo episódio é justamente essa: isolamento entre agentes não é suficiente quando existe uma ponte de confiança entre eles.
Se um agente com baixo privilégio pode influenciar outro que possui acesso maior, os dois precisam ser analisados como partes de uma mesma superfície de ataque.
E essa é uma mudança profunda no modelo tradicional de segurança.
Antes da era dos agentes, uma aplicação normalmente recebia uma solicitação, verificava a identidade e executava uma operação. Agora, uma solicitação pode passar por uma sequência de agentes, cada um interpretando o contexto, tomando decisões e acionando ferramentas diferentes.
Em cada uma dessas etapas existe a possibilidade de manipulação.
Por isso, a segurança de sistemas agênticos não pode depender apenas de filtros de prompt, listas de comandos ou sandboxes isolados. É necessário combinar identidade forte, menor privilégio, validação independente, controles de execução, monitoramento e revisão das relações de confiança entre agentes.
O episódio envolvendo o ADK mostra por que essa discussão deixou de ser teórica.
A IA já não está apenas produzindo texto.
Ela está começando a operar infraestrutura.
E quando uma inteligência artificial pode pedir para outra inteligência artificial fazer algo que ela própria não tem autorização para fazer, a pergunta mais importante deixa de ser se um agente é seguro isoladamente.
A pergunta passa a ser: até onde a cadeia de confiança entre esses agentes consegue chegar?
