O Google removeu três fluxos de trabalho de inteligência artificial do repositório Python do Agent Development Kit, o ADK, após pesquisadores demonstrarem uma cadeia de ataque capaz de transformar conteúdo não confiável do GitHub em comandos executados por um agente privilegiado.
A descoberta, divulgada pela Pillar Security, expõe um risco crescente: agentes de IA que analisam issues, escrevem código e abrem pull requests podem ampliar a superfície de ataque quando recebem credenciais e permissões excessivas.
O incidente não representa uma vulnerabilidade no pacote Python distribuído aos usuários. O problema estava na automação do repositório. Ainda assim, a falha de segurança no Google ADK mostra como uma identidade confiável pode ligar uma entrada pública a um processo privilegiado.
Como o ataque poderia começar no GitHub
A cadeia começava no workflow público issue-analyze.yml, executado quando uma nova issue era aberta. O fluxo enviava o conteúdo ao agente de triagem e publicava a análise por meio da conta adk-bot.
Segundo os pesquisadores, uma pessoa poderia inserir instruções maliciosas na issue. O agente processaria o texto e poderia publicar o comando /adk-issue-fix usando a conta do bot.
Outro workflow, o issue-fix.yml, aceitava o comando somente quando publicado por proprietário, membro ou colaborador. Como o adk-bot era reconhecido como colaborador, a verificação era aprovada.
O sistema confirmava quem havia publicado o comentário, mas não se a conta confiável havia sido induzida por conteúdo externo. A falha de segurança no Google ADK surgiu nessa separação incompleta entre identidade, intenção e autorização.
Resumo da cadeia de ataque
| Etapa | Componente | Risco |
|---|---|---|
| 1 | Issue pública | Entrada controlada por qualquer usuário |
| 2 | Agente de triagem | Interpretação de instruções maliciosas |
| 3 | Conta adk-bot | Publicação com identidade confiável |
| 4 | Workflow privilegiado | Execução baseada no autor |
| 5 | Runner de CI | Acesso a código e credenciais |
A prova de conceito demonstrou execução arbitrária de código no runner de integração contínua e exfiltração do token de acesso pessoal, o PAT, usado pelo bot.
Quais credenciais estavam disponíveis
O job privilegiado operava com diferentes segredos, incluindo o PAT do bot, uma chave da API do Google e uma credencial de conta de serviço do Google Cloud.
As permissões exatas do PAT não eram públicas. Também não ficou estabelecido se o token poderia enviar alterações diretamente para a branch principal. O relatório mostrou, porém, que ele era utilizado no checkout do repositório e em etapas para criar fork, branch e pull request.
Esse cenário reforça uma regra essencial de segurança da informação: o impacto de uma automação comprometida depende tanto da falha inicial quanto do alcance das credenciais disponíveis.
Credenciais e riscos
| Elemento | Uso previsto | Ponto de atenção |
| PAT do bot | Checkout e pull requests | Escopos não divulgados |
| Chave de API | Acesso ao agente de IA | Disponível no ambiente |
| Conta de serviço | Acesso ao Google Cloud | Permissões completas desconhecidas |
Em uma estratégia madura de segurança da informação, cada credencial deve ter escopo mínimo, duração limitada e monitoramento compatível com sua função.
Por que a lista de comandos não bloqueou o ataque
O runner rejeitava metacaracteres comuns do shell e permitia apenas comandos iniciados por gh ou git. A proteção parecia impedir comandos arbitrários, mas o agente também podia gravar arquivos.
O papel dos hooks do Git
O Git permite configurar caminhos personalizados para hooks por meio de core.hooksPath. Esses hooks são programas executáveis acionados durante determinadas operações.
Se um agente grava um arquivo malicioso e redireciona o Git para tratá-lo como hook, um comando permitido pode executar o payload. Assim, a lista restringia a aparência do comando, mas não seu efeito indireto.
A falha de segurança no Google ADK revela uma limitação importante: ferramentas legítimas também podem produzir resultados perigosos quando combinadas com escrita de arquivos e credenciais sensíveis.
O pacote Python do ADK foi comprometido?
Não há evidência pública de que uma versão maliciosa do ADK tenha sido distribuída. Os ataques foram provas de conceito controladas, e os pesquisadores não identificaram exploração em ambiente real.
O componente exposto era a automação do repositório, não o pacote instalado pelos desenvolvedores. Também não foi comprovado que alterações poderiam chegar diretamente à branch principal sem revisão humana.
O que foi confirmado e o que permanece incerto
| Confirmado | Não comprovado publicamente |
| Manipulação do agente por uma issue | Exploração real por invasores |
| Ativação do workflow privilegiado | Versão comprometida do ADK |
| Execução de código no runner | Escrita direta na branch principal |
| Exposição de credenciais | Alcance completo na nuvem |
Para equipes de DevSecOps e segurança da informação, alcançar o runner de CI já representa um risco relevante, especialmente quando o ambiente contém tokens e chaves.
Como o Google respondeu
O Google removeu os arquivos issue-analyze.yml, issue-fix.yml e pr-analyze.yml. O commit informou que os fluxos processavam conteúdo não confiável de issues e pull requests enquanto utilizavam credenciais amplas.
Os metadados do patch registram autoria em 9 de junho de 2026. A Pillar Security afirmou ter verificado a remoção em 2 de julho e informou que o Google confirmou a correção em 21 de julho. Em 4 de agosto de 2026, os três arquivos não foram encontrados no diretório principal de workflows.
A exclusão reduziu a exposição imediata, mas a falha de segurança no Google ADK deixa um alerta para outros projetos que adotam agentes autônomos em repositórios públicos.
Como proteger agentes de IA em pipelines
A primeira recomendação é separar identidades de bot. Um agente público de triagem não deve compartilhar a mesma identidade ou o mesmo nível de confiança de um agente autorizado a modificar código.
Também é necessário reduzir escopos de tokens, limitar ferramentas e impedir que texto não confiável produza sinais válidos de autorização. Comandos privilegiados devem depender de uma aprovação externa, impossível de ser gerada pelo próprio agente.
Comparativo de controles de segurança
| Área | Abordagem frágil | Abordagem mais segura |
| Identidade | Um bot para todas as tarefas | Contas separadas por função |
| Autorização | Confiança no autor do comentário | Aprovação externa e verificável |
| Tokens | Credenciais amplas | Tokens temporários e restritos |
| Ferramentas | Escrita habilitada por padrão | Capacidades mínimas e isoladas |
| Entrada pública | Texto tratado como instrução | Conteúdo tratado como dado não confiável |
Para a segurança da informação, o princípio central é direto: um agente não deve transformar uma entrada externa em autoridade interna sem uma barreira independente.
Um alerta para a automação com IA
A falha de segurança no Google ADK não prova que agentes de IA sejam inadequados para pipelines. Ela demonstra que esses sistemas devem ser tratados como componentes capazes de interpretar instruções adversariais e utilizar ferramentas legítimas de formas inesperadas.
À medida que agentes recebem acesso a repositórios e ambientes de nuvem, a proteção não pode depender apenas de filtros ou da identidade aparente de um bot. Privilégio mínimo, isolamento, aprovação humana e auditoria precisam acompanhar toda a cadeia.
A adoção de agentes também exige revisão contínua das permissões concedidas. Uma automação criada para economizar tempo pode se tornar um caminho para invasores quando utiliza a mesma identidade em tarefas públicas e privilegiadas.
A segurança da informação precisa fazer parte da arquitetura desses agentes desde o início, e não ser adicionada somente após a descoberta de um incidente. Isso inclui segmentação de funções, registros detalhados de atividade e mecanismos de interrupção para comportamentos inesperados.
O caso resume um novo desafio para o DevSecOps: proteger não apenas o código escrito por pessoas, mas também as decisões, credenciais e ações executadas por agentes automatizados.
A falha de segurança no Google ADK serve, portanto, como um alerta para empresas e projetos de código aberto que pretendem ampliar o uso de inteligência artificial em processos de desenvolvimento. Automatizar tarefas não significa automatizar a confiança.
