Pular para o conteúdo
Zumkai

Prompt injection: por que não existe correção definitiva, e o que fazer mesmo assim

Doze defesas contra prompt injection que reportavam taxa quase zero foram quebradas acima de 90%. Por que o problema é estrutural e o que reduz risco.

  • prompt injection
  • segurança de agentes
Card com o contraste entre as doze defesas que reportavam taxa próxima de zero e os mais de 90% de sucesso sob ataque adaptativo.
Sumário
  1. Prompt injection não é uma classe de bug
  2. O paper que quebrou doze defesas
  3. Por que os números publicados não podem ser comparados
  4. A honestidade de quem tem o melhor número
  5. O que reduz risco de verdade: arquitetura
  6. O que a defesa em camadas compra de verdade
  7. O que dá para fazer nesta semana
  8. Perguntas frequentes
  9. O que levar

Doze defesas publicadas contra prompt injection foram contornadas com mais de 90% de sucesso. A maioria delas havia reportado, no próprio artigo original, taxa de sucesso de ataque próxima de zero.

Quem fez isso foram catorze pesquisadores, com gente de OpenAI, Anthropic e Google DeepMind assinando o mesmo trabalho. O resultado saiu em outubro de 2025 e mudou o que significa dizer que uma defesa funciona.

A conclusão não é que aquelas doze defesas eram ruins. É que a régua estava errada: todas tinham sido avaliadas contra ataque estático, e nenhuma tinha sido testada contra alguém que estudasse o desenho da defesa antes de atacar.

Prompt injection não é uma classe de bug

O modelo recebe instrução e dado pelo mesmo canal, como texto, e não tem um mecanismo confiável para separar os dois. É essa a propriedade que o ataque explora.

Um SQL injection se resolve com prepared statement, porque o banco passa a receber comando e parâmetro por caminhos diferentes. Em um modelo de linguagem, esse caminho separado não existe. Você pode pedir que ele ignore instruções vindas de conteúdo externo, e ele vai obedecer na maioria das vezes — o que é diferente de garantir.

Vale desfazer uma confusão que a busca embaralha. Jailbreak é o usuário driblando a política do próprio modelo. Prompt injection é um terceiro colocando texto no caminho do agente para que ele aja em nome do usuário, contra o usuário. O segundo é mais grave, porque a vítima não participa.

O tamanho do problema aparece na lista da OWASP: entre os dez riscos do Top 10 para agentes, a injeção mapeia para seis. O caso que abriu essa categoria foi o EchoLeak, CVE-2025-32711, em que um único e-mail com instruções escondidas fazia o Microsoft 365 Copilot buscar e exfiltrar dados internos, sem nenhum clique.

Por onde o texto entra

Antes de defender, vale mapear a superfície. Todo lugar de onde o agente lê conteúdo que outra pessoa pode escrever é um ponto de entrada.

SuperfícieQuem consegue escrever ali
Issues e comentários do repositórioqualquer um, em projeto aberto
README e changelog de dependênciaquem mantém o pacote, e quem o comprometer
Página web que o agente abreo dono do site, e quem publicar comentário nele
E-mail e mensagem recebidaqualquer remetente
Resposta de ferramenta ou servidor MCPquem controla o servidor
Arquivo enviado pelo usuárioquem produziu o arquivo antes
Memória de sessões anterioresquem tiver acertado qualquer um dos itens acima

A última linha é a que costuma passar despercebida, e é a que dá alcance no tempo: uma instrução plantada uma vez pode ser relida por semanas.

Repare que conectar um servidor MCP adiciona uma linha inteira a essa tabela. A ferramenta amplia o que o agente consegue fazer e, no mesmo movimento, amplia de onde ele aceita texto.

O paper que quebrou doze defesas

Em 10 de outubro de 2025, catorze autores publicaram "The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections" (arXiv 2510.09023, acesso em 27/08/2026). O grupo inclui Milad Nasr, Nicholas Carlini e Chawin Sitawarin, com pesquisadores de OpenAI, Anthropic e Google DeepMind no mesmo trabalho.

O método foi direto: pegar defesas já publicadas e atacá-las com adversários adaptativos, que estudam o desenho da defesa e ajustam a estratégia contra ele. Quatro famílias de técnica entraram na conta — descida de gradiente, aprendizado por reforço, busca aleatória e exploração guiada por humano.

O que a defesa reportouO que aconteceu sob ataque adaptativo
A maioria das 12 publicou taxa de sucesso de ataque próxima de zeroAcima de 90% na maioria delas
Filtros por modelo: Protect AI Detector, PromptGuard, PIGuard, Model ArmorContornados
Defesas por conhecimento secreto: Data Sentinel, MELONContornadas
Treinamento adversarial e outras técnicasContornadas
Red teaming humano: 100%

O achado que importa está na distância entre as duas colunas. Sair de 2% para 8% seria ruído. O que aconteceu foi defesa publicada como praticamente impenetrável caindo quase sempre, assim que alguém dedicou esforço real ao problema.

A lição vale além deste assunto: número de segurança medido contra ataque estático produz confiança falsa. Sempre que você ler uma taxa de sucesso baixa, a pergunta útil é contra quem foi medida.

Por que os números publicados não podem ser comparados

<!-- [UNIQUE INSIGHT] -->

O mesmo modelo, avaliado no mesmo mês, aparece com 1% e com 63% de sucesso de ataque. As duas medições são legítimas, e comparar uma com a outra não é.

Duas medições do mesmo modelo, com métodos diferentes O Claude Opus 4.5 aparece com 1% de sucesso de ataque na medição da Anthropic, feita em navegador com salvaguardas ligadas e atacante Best-of-N em 100 tentativas, e com 63% na medição da Gray Swan, com ataque curado forte em 100 tentativas. Claude Opus 4.5 · sucesso de ataque em 100 tentativas Anthropic navegador, salvaguardas ligadas atacante Best-of-N 1% Gray Swan ataque curado "muito forte" escalada por tentativa 63% As duas estão certas. O que muda é o que cada uma chama de ataque.
Fontes: Anthropic, pesquisa sobre defesas em uso de navegador; Gray Swan, benchmark de 25 de novembro de 2025.

A Anthropic mediu o Claude Opus 4.5 com a extensão Claude for Chrome, salvaguardas ativas, contra um atacante adaptativo Best-of-N com 100 tentativas por ambiente, e publicou 1% (Anthropic, acesso em 27/08/2026). A Gray Swan mediu o mesmo modelo com ataques curados classificados como muito fortes e publicou 4,7% numa tentativa, 33,6% em dez e 63% em cem, em 25 de novembro de 2025 (The Decoder, acesso em 27/08/2026). Na mesma rodada, Gemini 3 Pro e GPT-5.1 chegaram a 92%.

O sucesso do ataque escala com o número de tentativas Na medição da Gray Swan, o Claude Opus 4.5 vai de 4,7% de sucesso de ataque em uma tentativa para 33,6% em dez tentativas e 63% em cem tentativas. 1 tentativa 4,7% 10 tentativas 33,6% 100 tentativas 63% taxa sem número de tentativas ao lado não informa nada
Fonte: benchmark Gray Swan sobre o Claude Opus 4.5, novembro de 2025.

O segundo gráfico mostra onde está o eixo real. Tentativa é barata para quem ataca: um agente que lê comentários de issue ou dependências recebe centenas de oportunidades por semana sem que ninguém precise insistir. Uma taxa medida em uma tentativa descreve um cenário que não existe em produção.

Daí o julgamento explícito deste post: taxa de sucesso de ataque publicada sem o número de tentativas e sem o tipo de atacante ao lado não informa nada. E isso vale para os números que eu mesmo citei aqui, que só entraram acompanhados do método.

A dificuldade é estrutural no mercado, não distração de quem escreve. Ao comparar os relatórios de quatro grandes laboratórios em junho de 2026, o VentureBeat observou que nenhum deles usou um arcabouço comum ou uma suíte adversarial compartilhada: a Anthropic reportou taxa de sequestro de agente de navegador, enquanto OpenAI, Google e Meta mediram injeção indireta em chamada de ferramenta ou em resumo de documento. São perguntas diferentes com o mesmo rótulo.

A honestidade de quem tem o melhor número

Quem publica o melhor resultado do mercado é quem diz, no mesmo texto, que o problema continua aberto.

A Anthropic escreve que 1% de sucesso de ataque, embora seja uma melhora significativa, ainda representa risco relevante, que nenhum agente de navegador é imune a prompt injection, e que compartilha os resultados para demonstrar progresso, sem afirmar que o problema esteja resolvido. Trata a questão como "longe de ser um problema resolvido", principalmente conforme os modelos passam a tomar mais ações no mundo real.

Guarde isso como régua comercial. Qualquer fornecedor que ofereça proteção total contra prompt injection está afirmando mais do que o melhor número público sustenta.

Quando aparecer uma taxa numa página de produto, quatro perguntas separam medição de marketing:

  1. Quantas tentativas por ambiente? Sem esse número, a taxa não tem significado. A diferença entre uma e cem tentativas foi de 4,7% para 63% na mesma medição.
  2. Que tipo de atacante? Ataque estático de uma lista pronta e adversário adaptativo que estudou o desenho da defesa são adversários diferentes. Foi essa distinção que derrubou as doze defesas.
  3. Quais salvaguardas estavam ligadas? O número da Anthropic vale para a configuração deles, com as proteções ativas. Ele não descreve o modelo puro atrás de uma API.
  4. Em que ambiente? Navegador, chamada de ferramenta e resumo de documento produzem números diferentes, e foi por isso que os relatórios dos quatro laboratórios não puderam ser comparados.

Se a página não responde às quatro, o número que ela publica serve para comunicação, não para decisão. Foi o mesmo critério que usei ao avaliar o que muda ao levar o Claude Code para produção: transparência sobre falha conta a favor, e promessa de imunidade conta contra.

O que reduz risco de verdade: arquitetura

As defesas que caíram no paper tinham algo em comum: dependiam de o modelo resistir. As duas abordagens que sobrevivem melhor mudam o desenho do sistema, de modo que resistir deixe de ser necessário.

Separar quem lê de quem age

Em março de 2025, o Google DeepMind publicou Defeating Prompt Injections by Design, descrevendo o CaMeL (arXiv 2503.18813, acesso em 27/08/2026). A ideia é antiga em segurança de software e nova nesse contexto: rastreamento de capacidades e integridade de fluxo de controle.

O sistema usa dois modelos com papéis distintos. Um LLM privilegiado só enxerga a consulta confiável do usuário e gera código Python representando a tarefa pretendida. Um interpretador próprio executa esse código e acompanha, para cada dado, metadados de origem e de uso permitido. Um LLM em quarentena processa o conteúdo não confiável e não tem acesso a ferramenta nenhuma.

O resultado no benchmark foi defender 67% dos ataques, chegando a zerar os ataques bem-sucedidos em alguns modelos. Não é imunidade, e a diferença de natureza é o que importa: a garantia passa a vir de onde o dado pode chegar, e não da disposição do modelo em obedecer.

Se você já divide trabalho entre agentes, essa fronteira é uma decisão de desenho e não de prompt — o mesmo raciocínio de quando delegar a um subagente, aqui com a validação entre eles virando requisito.

A Regra de Dois

Em 31 de outubro de 2025, a Meta AI publicou a formulação mais fácil de aplicar que encontrei nesta pesquisa (resumo de Simon Willison, 2 de novembro de 2025). Uma sessão de agente não deve combinar mais de duas destas três propriedades:

A Regra de Dois para sessões de agente Uma sessão de agente não deve combinar mais de duas entre: processar entrada não confiável, acessar dado sensível, e mudar estado ou se comunicar para fora. Combinações de duas propriedades são aceitáveis; as três juntas exigem contexto novo ou supervisão humana. A entrada não confiável B dado sensível ou privado C mudar estado ou falar para fora No máximo duas por sessão A + B ok A + C ok B + C ok A+B+C não Com as três juntas, a sessão precisa de contexto novo ou de um humano no circuito. Sem isso, o agente não deve operar sozinho.
Fonte: Agents Rule of Two, Meta AI, 31 de outubro de 2025.

O valor da regra está em reprovar desenho antes de custar dinheiro. Um agente que lê issues do repositório (A), tem acesso ao código-fonte privado (B) e pode abrir pull request (C) reúne as três, e é a configuração mais comum de agente de código que existe. Pela regra, ele não deveria rodar sem supervisão.

Duas saídas honestas para esse caso. Ou o agente perde o C e passa a produzir um diff que alguém aplica. Ou perde o A, e as issues entram por um caminho que já foi validado por uma pessoa.

Classificar leva minutos. Vale fazer com os agentes que já estão rodando na sua máquina:

ConfiguraçãoABCVeredito
Lê issues públicas, acessa código privado e abre pull requestsimsimsimnão roda sozinho
Lê issues públicas e entrega um diff para alguém aplicarsimsimnãoaceitável
Resume seus e-mails, sem enviar nadasimsimnãoaceitável
Resume seus e-mails e pode respondersimsimsimnão roda sozinho
Roda testes no repositório privado e comenta no pull requestnãosimsimaceitável
Pesquisa na web e escreve num documento seusimnãosimaceitável

A quarta linha merece atenção. Assistente que lê e responde e-mail sozinho é um dos primeiros agentes que qualquer pessoa monta, e reúne as três propriedades. Foi o formato do EchoLeak.

A quinta linha mostra o outro lado. Aquele agente toca dado sensível e muda estado, e ainda assim é defensável, porque nada de fora entra no contexto dele. Perceba que o veredito não depende de quanto poder o agente tem. Depende de esse poder encostar ou não em texto que um estranho escreveu.

Vale registrar uma observação incômoda: o CaMeL foi publicado em março de 2025 e, mais de um ano depois, a arquitetura de dois modelos com interpretador de capacidades continua rara em produto. O caminho está descrito. Adotá-lo custa reescrever a orquestração, e quase todo mundo preferiu ficar com o filtro.

O que a defesa em camadas compra de verdade

Filtro não garante nada, e mesmo assim vale ter. As duas afirmações convivem, e confundi-las leva a dois erros opostos: confiar no classificador como se fosse barreira, ou abandoná-lo porque não é.

O que uma camada de filtragem entrega, de forma verificável:

Reduz volume. A maior parte do que chega não é ataque adaptativo desenhado contra o seu sistema. É tentativa genérica, copiada, que um classificador barra. Isso libera atenção humana para o resto.

Impõe custo. As técnicas que quebraram as doze defesas no paper de outubro consumiram descida de gradiente, aprendizado por reforço e horas de exploração humana. Nada disso é gratuito. Contra a maioria dos alvos, o atacante desiste antes, porque existe alvo mais barato.

Gera sinal. Uma tentativa bloqueada é um registro com hora, origem e conteúdo. Sem a camada, o mesmo evento passa invisível. E a escalada por tentativa, que é o indicador que aparece primeiro, só existe se alguém estiver contando.

O que ela não entrega é garantia contra quem estuda o desenho antes de atacar. Essa é a fronteira, e ela é nítida: camada de filtragem trabalha em cima de probabilidade, camada de arquitetura trabalha em cima de possibilidade. Remover a ferramenta do alcance do agente muda o que é possível; treinar um filtro muda o que é provável.

A conclusão prática ficou com a Anthropic, que roda as duas coisas juntas e ainda assim publica que 1% de sucesso de ataque representa risco relevante. Camada some risco; nenhuma delas zera.

O que dá para fazer nesta semana

Nenhum destes passos exige trocar de modelo nem esperar por uma correção que não vem.

  1. Classifique cada agente pela Regra de Dois. Leva uma hora, não custa nada e reprova desenhos antes de eles chegarem a produção. Comece pelos agentes que já estão rodando.
  2. Tire a ferramenta perigosa do alcance em vez de pedir cuidado. Instrução no prompt cobre o caso em que o modelo obedece; remover a ferramenta cobre o resto. É o assunto de permissões e auto mode, e o CVE do Cursor mostrou o custo de confiar na allowlist.
  3. Separe o canal da tarefa do canal do material. O que chega de fora entra marcado como dado, e o que o agente executa vem de um caminho que passou por uma pessoa.
  4. Decida o que a memória pode guardar. Instrução plantada hoje é lida daqui a semanas, quando ninguém liga mais o comportamento estranho à origem. O critério de o que o agente guarda entre passos também é um critério de segurança.
  5. Registre tentativa, e não só sucesso. A escalada por tentativa é o sinal que aparece primeiro, e o único jeito de vê-lo é contar as tentativas. Um pico de conteúdo externo estranho chegando ao agente antecede o incidente.

Essas cinco medidas caem nas cinco camadas do harness, e nenhuma depende de o modelo resistir melhor.

Perguntas frequentes

O que é prompt injection?

É o ataque em que um terceiro insere instruções em conteúdo que o agente vai ler — um e-mail, um README, um comentário de issue, uma página web — para que o agente execute a intenção do atacante achando que cumpre a tarefa do usuário. Funciona porque instrução e dado chegam ao modelo pelo mesmo canal, como texto, sem um mecanismo confiável de separação.

Prompt injection tem solução definitiva?

Não. Em outubro de 2025, um paper com autores de OpenAI, Anthropic e Google DeepMind contornou 12 defesas publicadas com mais de 90% de sucesso, e a maioria delas havia reportado taxa próxima de zero; o red teaming humano chegou a 100%. A própria Anthropic, que publica o melhor número do mercado, afirma que o problema está longe de ser resolvido. O que existe é redução de risco por arquitetura.

Qual a diferença entre prompt injection e jailbreak?

Jailbreak é o usuário do sistema tentando contornar a política do modelo para obter uma resposta que ele não deveria dar. Prompt injection é um terceiro colocando texto no caminho do agente para que ele aja em nome do usuário e contra o interesse dele. Na injeção, a vítima não participa do ataque e frequentemente nem percebe.

Filtro ou classificador de prompt resolve?

Não sozinho. Entre as defesas contornadas no paper de outubro de 2025 estavam filtros por modelo como Protect AI Detector, PromptGuard, PIGuard e Model Armor. Classificador reduz o volume de ataque trivial, o que tem valor, e não sustenta a promessa de bloquear um adversário que ajusta a estratégia contra o desenho do filtro.

Dá para colocar agente em produção com esse risco aberto?

Dá, com a mesma lógica com que se coloca software em produção sabendo que existem vulnerabilidades não descobertas: limitando o estrago possível. Classifique a sessão pela Regra de Dois, reduza o que a ferramenta acionada consegue fazer, isole a execução e registre o suficiente para investigar. O risco que sobra deve ser um risco que você aceitou de propósito.

O que levar

  • Doze defesas publicadas caíram acima de 90% sob ataque adaptativo, e a maioria havia reportado taxa próxima de zero. Red teaming humano: 100%.
  • Injeção é propriedade estrutural de sistema que interpreta linguagem natural. Não existe o prepared statement equivalente.
  • Taxa sem método ao lado não informa nada. O mesmo modelo aparece com 1% e 63% conforme quem mede, e os laboratórios não usam suíte adversarial comum.
  • O que funciona vem do desenho: separar quem lê dado não confiável de quem chama ferramenta, e não juntar as três propriedades da Regra de Dois.
  • O CaMeL está publicado desde março de 2025 e segue pouco adotado. O caminho existe; o custo é reescrever a orquestração.

O próximo post do cluster trata da camada que fecha a maior parte desses riscos: onde travar o agente antes de ele agir. A base de tudo continua no pilar sobre harness engineering, que descreve as cinco camadas em que estas defesas se encaixam.

Leia também