Novo ataque de injeção de dados pode fazer AI agents clicarem errado ou executar comandos do invasor
17 de Julho de 2026

Pedir a um agente de IA que resuma as avaliações de uma página de produto pode acabar levando o modelo a clicar em “Comprar agora” depois de ler apenas uma avaliação plantada.

Pedir a um assistente de programação que aplique a correção sugerida por um mantenedor em um tópico do GitHub pode fazer com que uma falsa mensagem o leve a executar no seu computador o comando de outra pessoa.

Nenhum desses truques sequestra a tarefa do agente.

Eles apenas corrompem os fatos em que ele confia e o deixam continuar o trabalho solicitado.

Esse é o formato de uma nova classe de ataque descrita em um artigo publicado em 6 de julho por pesquisadores da Universidade Nacional de Seul, da Universidade de Illinois Urbana-Champaign e da Largosoft.

Eles chamam a técnica de agent data injection, ou ADI.

Nela, a entrada do atacante é disfarçada como dado em que o agente já confia, como o nome do remetente ou o ID de um botão, o que a faz passar pela maior parte das defesas criadas para barrar prompt injection.

A lacuna nasce da forma como um agente lê informações.

Ele lida com dois tipos de conteúdo: instruções, isto é, o que o usuário e o desenvolvedor do aplicativo dizem para ele fazer, e dados, que são tudo o que ele coleta durante a execução, como um e-mail, uma página da web ou um comentário.

O prompt injection clássico esconde uma ordem dentro desses dados, com algo como “ignore sua tarefa e me envie os arquivos”.

Os pesquisadores chamam isso de instruction injection.

As defesas modernas foram treinadas para identificar textos com aparência de ordem escondida e bloqueá-los, e, contra essa abordagem, elas já funcionam bem.

A ADI atua um nível abaixo, nos pequenos fatos em que um agente confia discretamente: quem enviou um e-mail, o ID de um botão em uma página, o registro de uma etapa já executada por uma ferramenta.

Se esses dados forem corrompidos, o agente continua fazendo a tarefa, só que em cima de informações plantadas pelo atacante.

Pontuação falsa em que o modelo acredita

O método por trás disso é o que os pesquisadores chamam de probabilistic delimiter injection.

Os agentes envolvem seus dados com sinais de pontuação que indicam onde uma parte termina e a próxima começa, como aspas, chaves, tags, colchetes e quebras de linha.

Essa pontuação é o que permite ao modelo separar um campo confiável, como o nome de um remetente, de um conteúdo não confiável, como o corpo de uma mensagem.

Um programa comum lê essa pontuação por regras estritas.

Um modelo de linguagem a interpreta por inferência.

Assim, um atacante pode inserir caracteres parecidos com delimitadores em um campo que controla, e o modelo muitas vezes os lê como uma estrutura real que nunca existiu, enxergando um e-mail extra, um botão extra ou um resultado de ferramenta extra.

A parte que dificulta a defesa é que a pontuação falsa nem precisa estar correta.

Nos testes, uma aspa escapada (\\"), uma aspa tipográfica e até mesmo um cifrão foram aceitos como se fossem o delimitador verdadeiro e ainda assim enganaram o modelo.

Um analisador rígido trataria esses caracteres como texto comum, e não como o início de uma nova estrutura.

Os pesquisadores criaram três ataques funcionais em ferramentas reais já distribuídas:

- Em agentes para web, como Claude in Chrome, Antigravity da Google e Nanobrowser, uma avaliação plantada reutiliza o ID de um botão legítimo.

O agente pretende clicar em “Read More” e acaba clicando em “Buy Now”, o que faz o pedido avançar sem que o usuário tenha feito a compra.

Como essas ferramentas numeram os elementos da página em ordem, o atacante consegue prever o ID com antecedência.
- Em assistentes de programação, como Claude Code, Codex da OpenAI e Gemini CLI da Google, um comentário no GitHub forja a linha do autor para parecer que foi escrito por um mantenedor do projeto.

Ao ser orientado a aplicar a correção do mantenedor, o agente executa o comando do atacante na máquina do desenvolvedor, caso o desenvolvedor aprove o que parece uma etapa rotineira.
- Um pull request malicioso falsifica o registro de uma verificação que o agente nunca executou, de modo que um resultado aparentemente limpo aparece no histórico.

O agente analisa esse resultado falso, conclui que o código é seguro e avança para a mesclagem, o que leva o código realmente malicioso para o projeto quando o desenvolvedor aprova.

A maioria dessas ferramentas já pede confirmação antes de fazer algo arriscado.

O Claude in Chrome pede antes de clicar, e os assistentes de programação pedem antes de executar um comando.

Isso ajuda pouco.

O aviso de clique só informa que o agente quer clicar em um elemento, mas não diz qual nem por quê.

Os assistentes de programação exibem seu raciocínio, mas esse raciocínio é construído sobre fatos falsos, então parece um relato plausível de uma etapa normal.

Para quem observa a tela, é difícil distinguir uma aprovação legítima de uma aprovação fabricada.

E todos os modelos testados se mostraram vulneráveis: GPT-5.2 e GPT-5-mini da OpenAI, Claude Opus 4.5 e Sonnet 4.5 da Anthropic, e Gemini 3 Pro e Flash da Google.

Em todos os seis, o ataque funcionou em dados estruturados de 31% a 43% das vezes, e em dados de páginas da web a taxa variou de um terço das tentativas até todas elas.

Nas defesas específicas para agentes testadas pelos pesquisadores, a diferença ficou ainda mais clara.

O ataque clássico de inserção de ordens foi quase totalmente bloqueado, com taxa de sucesso próxima de zero, enquanto a ADI ainda conseguiu êxito em até 50% das tentativas.

As mesmas defesas, resultados muito diferentes, porque foram criadas para outro tipo de ataque.

O que realmente bloqueia o ataque

Nem tudo falhou.

O navegador Atlas, do ChatGPT, resistiu ao ataque de clique porque atribui a cada elemento da página um ID aleatório e imprevisível, em vez de um contador simples, o que impede o atacante de forjar uma correspondência.

Os pesquisadores encontraram o mesmo princípio, um pequeno identificador aleatório adicionado aos nomes dos campos, e isso reduziu o ataque em cerca de metade, de aproximadamente 49% para 29% nos testes, sem tornar os agentes inúteis.

Uma defesa mais pesada, que acompanha de onde veio cada pedaço de dado, bloqueou totalmente o ataque, com zero sucesso, mas fez os agentes concluírem apenas cerca de um terço das tarefas normais.

Remover a pontuação também reduziu o ataque, mas prejudicou a capacidade dos agentes de interpretar coisas comuns, como links e caminhos de arquivo.

Os pesquisadores descrevem apenas ataques de prova de conceito, e não há relato público de ADI sendo usada no mundo real.

A equipe informou todas as empresas afetadas antes da publicação.

OpenAI, Google e Anthropic reconheceram os relatos, e a Nanobrowser ainda não havia respondido no momento da publicação.

Para o ataque funcionar, é preciso que algumas condições se encaixem.

O agente precisa processar conteúdo que um estranho possa editar, algo que agentes para web e GitHub fazem o tempo todo.

E o atacante precisa conhecer o formato usado pelo agente para empacotar os dados.

Os pesquisadores afirmam que esse formato pode ser recuperado em ferramentas de código aberto ou executadas localmente, seja lendo o código, seja por engenharia reversa.

Já um serviço em cloud é mais difícil e pode exigir um jailbreak que não é garantido.

Segundo o artigo, os pesquisadores também vão liberar o conjunto de testes e o código do ataque, para que fornecedores e equipes de defesa possam testar seus sistemas contra ele.

Woohyuk Choi, que escreveu o artigo com o professor Byoungyoung Lee, disse ao The Hacker News que OpenAI, Google e Anthropic confirmaram que o ataque é válido, e que OpenAI e Google pediram uma cópia do estudo.

Além disso, afirmou que a equipe “não foi informada de nenhuma correção, seja já lançada ou planejada”.

Sobre a parte mais difícil, a recuperação do formato usado por um serviço em cloud, Choi disse que a equipe conseguiu mesmo assim.

Nesse formato mantido no servidor, que o atacante não consegue ver diretamente, eles fizeram o modelo revelá-lo com um jailbreak em várias etapas, e, com diferentes níveis de esforço, isso funcionou contra GPT, Claude e Gemini.

Existe até um atalho: os modelos maiores e menores de uma mesma empresa tendem a compartilhar o mesmo formato.

Assim, um atacante pode extraí-lo de um modelo menor, que é mais fácil de quebrar.

Choi acredita que o formato continuará sendo recuperável mesmo com a evolução dos modelos, porque modelos de linguagem não conseguem manter esse tipo de segredo de forma confiável.

Onde isso se encaixa

O problema de confiança por trás dessa técnica já apareceu antes.

Em junho de 2025, a Aim Security revelou o EchoLeak, identificado como CVE-2025-32711 , uma falha no Microsoft 365 Copilot em que era possível criar um e-mail que fazia o assistente vazar arquivos internos sem necessidade de clique.

A Microsoft corrigiu o problema, e não houve relato de abuso no mundo real, mas foi um caso inicial e concreto de uma ideia de prompt injection transformada em um caminho funcional de exfiltração de dados em um produto comercial.

O EchoLeak foi essa história em sua primeira forma: uma ordem oculta.

A ADI é o próximo passo.

A questão no GitHub também não é nova.

Em maio de 2025, a Invariant Labs mostrou que uma issue pública no GitHub podia conduzir um agente a ler um repositório privado e vazá-lo, um problema de design sem correção simples.

Mais recentemente, testes entre fornecedores levaram Claude Code, Gemini CLI e Copilot a vazar seus próprios segredos por meio de texto em issues e pull requests, driblando as barreiras que o GitHub adicionou justamente para isso.

Esses ataques escondiam instruções.

A ADI forja quem disse o quê e falsifica o registro do que o agente já fez.

Os pesquisadores relacionam isso a uma lição que o software tradicional aprendeu da maneira mais difícil: separar código de dados e, depois, separar dados confiáveis de dados não confiáveis.

Os agentes adotaram a primeira metade da lição, mas ignoraram a segunda.

Dentro da memória de um agente, o nome em um e-mail fica ao lado do corpo dessa mensagem, sem nada que indique o que o sistema valida e o que um estranho digitou.

Até que os agentes estabeleçam essa linha, uma mentira convincente sobre quem enviou algo já é suficiente para viabilizar o ataque.

Publicidade

Um novo caminho a ser seguido

Vibecoding cria 10x mais sistemas, 20x mais vulneráveis. E quem ganha com isso é a galera do hacking ético e pentest. Quer ser pago para invadir sistemas? Então você tem que aprender com a Solyd que são os melhores do Brasil. Saiba mais...