Prompt injection: dado lido virando instrução

Injeção de prompt é a vulnerabilidade nº 1 da OWASP para aplicações com LLM. A defesa leva o ataque de 25% para 8% — reduz muito, nunca zera.

Prompt injection, ou injeção de prompt, é o ataque em que um texto lido pelo modelo é interpretado como instrução em vez de dado — fazendo o sistema obedecer a quem escreveu aquele texto, e não a quem o opera. É a vulnerabilidade número um da lista da OWASP para aplicações com modelos de linguagem, classificada como LLM01:2025. E a própria OWASP escreve algo mais duro do que a maioria dos fornecedores admite: dada a natureza estocástica desses modelos, “não está claro se existem métodos infalíveis de prevenção”. Há medição: no benchmark AgentDojo, um detector de injeção derruba o sucesso do ataque de menos de 25% para 8%. Não é um defeito à espera de correção — é propriedade da arquitetura. Aplicações com IA apagam a fronteira entre dado e instrução, e o modelo não tem como separar com segurança o que é conteúdo do que é comando. Para quem opera marketing, isso importa porque o insumo do setor é justamente texto escrito por terceiros.

Direta e indireta: a segunda é a que importa

A versão direta é alguém digitando “ignore suas instruções” no chat. É a mais conhecida e a menos perigosa.

A indireta é o problema real: 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. Não exige acesso nenhum à sua interface. Se um agente lê e-mails de leads, o texto do lead é código não confiável.

⚠️ Defesa reduz, mas nunca zera

Há medição com amostra declarada. No benchmark AgentDojo, com 97 tarefas realistas e 629 casos de teste de segurança:

CenárioSucesso do ataque
Sem defesa específicamenos de 25%
Com detector de injeção8%
⚠️ Pior ambiente medido92%

Três leituras: a defesa funciona e não elimina — 8% não é zero, e o atacante só precisa de uma tentativa que passe; ela custa de 15% a 20% de utilidade; e a média esconde o desastre, porque num dos ambientes o ataque funcionou em 92% das vezes.

Sobre os “95% dos ataques bloqueados” que fornecedores anunciam: não localizamos paper, metodologia nem amostra para esses números. E há um problema anterior ao da origem — em segurança, 95% descreve uma falha a cada vinte tentativas, contra um adversário que pode tentar quantas vezes quiser.

O que isso muda na prática

A forma mais útil de avaliar risco não é procurar o ataque — é procurar a combinação que o torna possível. O perigo aparece quando três coisas coexistem:

  • Acesso a dados privados — CRM, base de clientes, histórico
  • Exposição a conteúdo não confiável — e-mails, páginas, tickets
  • Capacidade de comunicar para fora — enviar, chamar API, escrever

Remova qualquer um dos três e o vetor se fecha — a decisão de arquitetura mais barata disponível, e que não depende de comprar nada. Um SDR com IA que lê a caixa de entrada, consulta o CRM e envia e-mail tem os três elementos completos.

Trate como se trata fraude em meio de pagamento: orçamento de risco, não item de checklist. Reduz-se, monitora-se, limita-se o dano — não se elimina.

A análise completa, com os controles da OWASP e os cenários de martech, está no artigo Prompt injection: o ataque que a OWASP diz não saber prevenir. Veja também jailbreak — que a OWASP classifica como uma forma de injeção de prompt, não como categoria separada — e MCP.

Fontes

Leitura das fontes em 17/08/2026.

Compartilhe:

Outros termos do universo martech que você precisa conhecer!

Sumário

Receba o melhor conteúdo sobre Marketing e Tecnologia

comunidade gratuita

Cadastre-se para o participar da primeira comunidade sobre Martech do brasil!