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

Sumário
- Prompt injection não é uma classe de bug
- O paper que quebrou doze defesas
- Por que os números publicados não podem ser comparados
- A honestidade de quem tem o melhor número
- O que reduz risco de verdade: arquitetura
- O que a defesa em camadas compra de verdade
- O que dá para fazer nesta semana
- Perguntas frequentes
- 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ície | Quem consegue escrever ali |
|---|---|
| Issues e comentários do repositório | qualquer um, em projeto aberto |
| README e changelog de dependência | quem mantém o pacote, e quem o comprometer |
| Página web que o agente abre | o dono do site, e quem publicar comentário nele |
| E-mail e mensagem recebida | qualquer remetente |
| Resposta de ferramenta ou servidor MCP | quem controla o servidor |
| Arquivo enviado pelo usuário | quem produziu o arquivo antes |
| Memória de sessões anteriores | quem 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 reportou | O que aconteceu sob ataque adaptativo |
|---|---|
| A maioria das 12 publicou taxa de sucesso de ataque próxima de zero | Acima de 90% na maioria delas |
| Filtros por modelo: Protect AI Detector, PromptGuard, PIGuard, Model Armor | Contornados |
| Defesas por conhecimento secreto: Data Sentinel, MELON | Contornadas |
| Treinamento adversarial e outras técnicas | Contornadas |
| — | 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 é.
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 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:
- 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.
- 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.
- 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.
- 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:
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ção | A | B | C | Veredito |
|---|---|---|---|---|
| Lê issues públicas, acessa código privado e abre pull request | sim | sim | sim | não roda sozinho |
| Lê issues públicas e entrega um diff para alguém aplicar | sim | sim | não | aceitável |
| Resume seus e-mails, sem enviar nada | sim | sim | não | aceitável |
| Resume seus e-mails e pode responder | sim | sim | sim | não roda sozinho |
| Roda testes no repositório privado e comenta no pull request | não | sim | sim | aceitável |
| Pesquisa na web e escreve num documento seu | sim | não | sim | aceitá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.
- 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.
- 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.
- 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.
- 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.
- 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
OWASP Top 10 para agentes: as dez ameaças de 2026, e o que já aconteceu com cada uma
A lista oficial do OWASP Top 10 para agentes de IA, de ASI01 a ASI10, com o incidente real e datado que já explorou cada um dos dez riscos.
- owasp
- segurança de agentes
Guardrails para agentes: onde travar antes de ele agir
Das falhas documentadas de agentes, 40 em 52 eram evitáveis por camadas do harness. Onde colocar a trava e por que classificador não basta.
- guardrails
- segurança de agentes
Context engineering: os quatro pilares e por que a janela cheia atrapalha
Em 18 modelos testados, o desempenho cai conforme a entrada cresce, antes de a janela encher. Os quatro pilares para manter o contexto pequeno.
- context engineering
- context rot


