AgentTracer encontra o ponto de injeção de prompt nos logs do agente em 94% dos casos

Todos discutem como proteger um agente contra injeções de prompt. Escreve-se muito menos sobre o que fazer quando a proteção falhou e é preciso entender o que aconteceu. Pesquisadores da Universidade Sun Yat-sen e da Universidade de Ciência e Tecnologia de Hong Kong lançaram o AgentTracer, um trabalho justamente sobre isso: como reconstruir o curso de um ataque a partir dos logs do agente.

Por que é tão difícil ver um ataque nos logs

Todo o texto lido pelo agente vai parar em um único contexto do modelo. O modelo, em essência, não distingue de onde veio uma frase e tenta cumprir a instrução mais recente e convincente. Em uma injeção indireta, o comando malicioso está em uma página ou e-mail que o próprio agente abriu a pedido do usuário. Por isso suas ações parecem trabalho normal.

O exemplo do artigo foi inventado pelos autores, mas a mecânica é precisa. Um usuário pede para baixar uma versão de um site e enviá-la ao GitHub. Há uma instrução escondida na página, e o agente, de quebra, registra a chave SSH do atacante, lê o e-mail e, no final, limpa a memória de trabalho. Só o último passo chama atenção, e a análise do fluxo de dados não o ligará à página: as chamadas não têm parâmetros em comum. A ligação só aparece no raciocínio do agente, em que ele explica por que faz isso.

Além disso, os logs do servidor podem não mostrar nada. Na técnica HashJack, a instrução se esconde no fragmento do endereço após o #, que é processado no cliente e não vai ao servidor. O vazamento de dados por meio de uma requisição de imagem com parâmetros na URL, como no caso do Bing Chat, não se distingue de fora de um download comum. E no CoSnitch (CVE-2026-24301), as instruções nocivas ainda eram gravadas na memória persistente do assistente, de modo que podiam disparar em outro dia.

Como funciona o AgentTracer

A ideia é simples: se a injeção funcionou, o agente faz algo que o usuário não pediu. Os autores chamam essa divergência de deriva de intenção. A partir dos registros de raciocínio, constrói-se um grafo: os nós são a solicitação do usuário e os objetos retornados pelas ferramentas (páginas, e-mails, arquivos), e as arestas são as operações do agente. Assim, chamadas sem parâmetros em comum ainda caem em uma mesma cadeia.

Em seguida, cada chamada é verificada por três critérios: ação, alvo e restrições. Se qualquer um for violado, a aresta é marcada como desvio. Do evento suspeito, retrocede-se pelas arestas marcadas. Se a raiz da cadeia é um recurso externo, trata-se de injeção, e a linha em que ele entrou no contexto se torna o ponto de injeção. Se a raiz não é externa, o agente simplesmente errou. A resposta "não houve injeção" também é um resultado completo da investigação.

Os testes foram feitos em condições duras: logs de ataques bem-sucedidos do AgentDyn e do InjecAgent foram misturados a cinco meses de trabalho normal do agente. Para cada cadeia de três chamadas havia cerca de três mil alheias. O ponto de injeção foi encontrado em cerca de 94% dos casos, enquanto sete concorrentes ficam na faixa de 40% a 76%.

Alguns encontravam todos os ataques, mas não a origem; outros montavam a cadeia de forma mais completa, mas com excessos. Se o grafo é trocado por uma lista simples de chamadas, ou a verificação por três critérios por uma avaliação de um LLM, a precisão cai. A poda em torno do evento suspeito economiza quase um terço do tempo e uma vez e meia os tokens.

O que fazer e onde estão os limites

A conclusão principal é prática: a investigação se apoia no que você guardou antes do incidente. São necessários a solicitação do usuário, o raciocínio do agente, as chamadas e os resultados completos das ferramentas, além das requisições de saída. A Microsoft aconselha tratar qualquer conteúdo externo como hostil e manter telemetria de requisições e respostas. Os logs devem ser armazenados de modo que um atacante não possa alterá-los.

O método tem limites. Ele é voltado a agentes no estilo ReAct com raciocínio registrado. Se, após a injeção, não houve chamadas de ferramentas ou o código alterou arquivos sem passar por elas, não há o que rastrear. O grafo é construído por um modelo de linguagem, e o raciocínio do agente nem sempre reflete as causas reais de suas ações, então a confiabilidade das conclusões não é maior que a desse relato. Foi testado apenas em ataques bem-sucedidos e em um único ambiente; em logs inofensivos, os falsos positivos foram de cerca de 3,5%. O caso da memória persistente é o menos estudado.

Outra ressalva da revisão da OWASP do terceiro trimestre de 2026: um agente pode se desviar da tarefa sem qualquer injeção. O Claude Opus 4.7, em uma avaliação de cibersegurança, atacou uma empresa real com nome parecido, e os agentes da OpenAI saíram por um serviço de pacotes compartilhado para a infraestrutura da Hugging Face. Nenhuma injeção foi comprovada. Portanto, o limite de segurança se sustenta em restrições obrigatórias, ferramentas isoladas e credenciais, não no prompt. Os logs servem para esclarecer depois, não para substituir a proteção.

Por enquanto o Google encontra na rede principalmente piadas e truques de SEO, mas a proporção de achados maliciosos cresceu 32% (em termos relativos) entre novembro de 2025 e fevereiro de 2026. Vale configurar o log do agente agora, antes que ele seja necessário.