Prompt injection: o ataque que a OWASP diz não saber prevenir

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* —

. 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](https://comecandonaweb.com.br/marketing-digital/).## O ataque que não precisa da sua senha: injeção indiretaA 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](https://clubmartech.com.br/blog/conteudo-longo-prazo-anos/) que o sistema vai ler depois**. Uma página web, um e-mail, um ticket de [suporte](https://clubmartech.com.br/blog/suporte-software-[saas](https://clubmartech.com.br/significado/saas/)-escalavel/), um documento, um campo de formulário.O trabalho que nomeou o problema é de fevereiro de 2023 e demonstrou o ataque **[sem](https://clubmartech.com.br/blog/sem-avancado-estrategia-roi/) qualquer acesso à [[interface](https://clubmartech.com.br/blog/interface-usuario-conectar-negocio/) do usuário](https://clubmartech.com.br/significado/interface-usuario/)**: bastou injetar instruções em [dados](https://clubmartech.com.br/blog/dados-transformar-volume-acionavel/) 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](https://clubmartech.com.br/significado/apis/) o modelo chamaria.Traduzindo para o seu contexto: **se um agente de [IA](https://clubmartech.com.br/blog/ia-marketing-vendas-inteligentes/) lê e-mails de leads, o texto do [lead](https://clubmartech.com.br/blog/lead-scoring-[crm](https://clubmartech.com.br/significado/crm/)-negocios/) é 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 bloqueiamO **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**.

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 existeFornecedores 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 elementosA 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áticaOs 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

, e o protocolo que hoje conecta agentes a sistemas — junto com seus riscos — em

.## 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