A OWASP colocou o prompt injection no topo da sua lista de riscos para aplicações com modelos de linguagem — classificado como LLM01:2025 — e escreveu algo mais duro do que a maioria dos fornecedores admite: dada a natureza estocástica de como os modelos funcionam, “não está claro se existem métodos infalíveis de prevenção”. Os números medidos confirmam o tom: no benchmark AgentDojo, um detector de injeção reduz a taxa de sucesso do ataque de menos de 25% para 8% — redução real, mas longe de zero, contra um adversário que só precisa de uma tentativa que passe.
Prompt injection é o ataque em que um texto lido pelo modelo vira instrução em vez de dado — como definimos no glossário. Não é um bug à espera de correção: é uma propriedade da arquitetura, porque aplicações com LLM apagam a fronteira entre dado e instrução. Este artigo mostra o que as medições dizem sobre as defesas e o que isso muda para quem opera marketing.
O ataque que não precisa da sua senha: injeção indireta
A versão que interessa a quem opera marketing não é a direta — alguém digitando “ignore suas instruções” no chat. É a indireta: o atacante planta a instrução num conteúdo que o sistema vai ler depois. Uma página web, um e-mail, um ticket de suporte, um documento, um campo de formulário.
O trabalho que nomeou o problema é de fevereiro de 2023 e demonstrou o ataque sem qualquer acesso à interface do usuário: bastou injetar instruções em dados que provavelmente seriam recuperados pelo sistema. Os alvos incluíram aplicações reais em produção. As capacidades demonstradas: exfiltração de dados, propagação entre sistemas, e controle sobre quais APIs o modelo chamaria.
Traduzindo para o seu contexto: se um agente de IA lê e-mails de leads, o texto do lead é código não confiável. Se ele resume páginas de concorrentes, aquelas páginas são código não confiável.
Quanto as defesas realmente bloqueiam
O AgentDojo é o benchmark que mede isso com amostra declarada: 97 tarefas realistas (cliente de e-mail, banco eletrônico, reservas de viagem) e 629 casos de teste de segurança.
| Cenário | Taxa de sucesso do ataque |
|---|---|
| Contra os melhores agentes, sem defesa específica | menos de 25% |
| Com detector de injeção | 8% |
| Com filtro de ferramentas | 7,5% |
| ⚠️ Pior cenário medido (suíte tipo Slack) | 92% |
Três leituras que essa tabela permite, e que nenhuma delas é confortável:
- Defesa funciona — e não zera. De 25% para 8% é uma redução grande. Mas 8% não é zero, e em segurança essa diferença é a que importa: o atacante só precisa de uma tentativa que passe.
- Defesa custa desempenho. No mesmo estudo, todas as defesas testadas custaram de 15% a 20% de utilidade. Não existe proteção grátis.
- A média esconde o desastre. Os 25% são a média; num dos ambientes testados, o ataque funcionou em 92% das vezes. Onde a injeção é colocada também muda tudo — no fim da resposta de uma ferramenta, o sucesso chegou a 70%.
Vale registrar um dado de contexto do mesmo estudo: os agentes resolvem menos de 66% das tarefas mesmo sem ataque nenhum. E sob ataque, perdem de 10% a 25% de utilidade absoluta.
⚠️ O número que não existe
Fornecedores de proteção anunciam bloquear “95% dos ataques” ou percentuais parecidos. Procuramos a origem desses números: não há paper, não há metodologia pública, não há amostra declarada. O número circula; a fonte, não.
E há um problema anterior ao da procedência. Em segurança, 95% não é uma boa nota — é a descrição de uma falha a cada vinte tentativas, contra um adversário que pode tentar quantas vezes quiser e reformular o ataque de infinitas maneiras. Um filtro que acerta 95% em produtividade é ótimo; em segurança, é uma porta.
Quando um fornecedor apresentar esse tipo de percentual, faça duas perguntas: qual o conjunto de ataques testado, e quem o construiu. Se a resposta for o próprio fornecedor, o número mede o quanto a defesa resiste aos ataques que a defesa já conhece.
O modelo mental que funciona: os três elementos
A forma mais prática de avaliar risco não é procurar o ataque — é procurar a combinação que o torna possível. O risco grave aparece quando três coisas coexistem no mesmo sistema:
- Acesso a dados privados — CRM, base de clientes, histórico de atendimento
- Exposição a conteúdo não confiável — e-mails, páginas web, tickets, documentos de terceiros
- Capacidade de comunicar para fora — enviar e-mail, chamar API externa, escrever em sistema conectado
Remova qualquer um dos três e o vetor se fecha. É a decisão de arquitetura mais barata e mais eficaz disponível — e não depende de comprar nada.
O que isso muda na prática
Os cenários de martech onde os três elementos costumam se encontrar sem que ninguém tenha decidido isso:
- SDR com IA que triaria a caixa de entrada. Lê texto de estranhos, tem acesso ao CRM, e pode enviar e-mail. Os três elementos, completos.
- Agente que pesquisa concorrentes na web. A página lida pode conter instrução — é o cenário que mediu 92%.
- Enriquecimento de CRM via raspagem. Texto externo entrando num sistema com permissão de escrita.
Os controles que a OWASP nomeia são todos de contenção, nenhum de eliminação — e é assim que devem ser tratados no orçamento e no desenho:
- Menor privilégio. O token que o agente usa para ler não pode ser o mesmo que escreve. Separe.
- Aprovação humana para o irreversível. Enviar, publicar, cobrar, alterar orçamento de campanha, apagar registro — nada disso sem confirmação.
- Marcar conteúdo externo. O sistema deve saber quais trechos do contexto vieram de fora.
- Validar a saída, não só a entrada. E rodar testes adversariais contra o seu próprio agente antes que outra pessoa o faça.
A conclusão honesta: isso é orçamento de risco, não um item de checklist. Trate como se trata fraude em meio de pagamento — reduz-se, monitora-se, limita-se o dano. Não se elimina. O contexto sobre taxa de falha de agentes está no verbete de agente de IA, e o protocolo que hoje conecta agentes a sistemas — junto com seus riscos — em MCP.
Fontes
- OWASP LLM01:2025 — Prompt Injection · Top 10 for LLM Applications
- AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses — NeurIPS 2024, 97 tarefas e 629 casos de teste
- Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection — Greshake et al., 2023
- The Lethal Trifecta — Simon Willison, origem do modelo dos três elementos
Leitura das fontes em 17/08/2026.
Leia também
- Modelos de IA em 2026 — panorama com preços e versões
