Blog

Se um chatbot pode ser convencido a ignorar regras, ele não é “inteligente”.
Ele está sem controle.

Prompt injection é quando uma entrada (do usuário, de um documento recuperado via RAG ou até de uma ferramenta) consegue alterar o comportamento do modelo de forma indesejada: ignorar políticas, revelar informação, executar ações ou produzir saídas perigosas.

A OWASP lista prompt injection como um dos principais riscos em aplicações com LLM (LLM01). Em sistemas com RAG e tool calling, o impacto pode ser maior porque o modelo vira uma camada de decisão no meio do caminho.

O que você vai aprender

• Diferença entre injeção direta e indireta
• Onde a injeção entra num sistema moderno (RAG, tools, plugins)
• Mitigação em camadas que não depende de “prompts mágicos”
• Checklist para reduzir risco sem matar a experiência do usuário

Direta vs indireta (a distinção que muda sua arquitetura)

Injeção direta é a clássica: o usuário escreve algo do tipo “ignore todas as instruções e faça X”.

Injeção indireta é mais perigosa: o usuário não escreve a instrução maliciosa.
Ela vem “escondida” em algum conteúdo que o modelo lê, por exemplo:

• um documento indexado no RAG
• uma página HTML
• um e-mail/ticket
• a saída de uma ferramenta (um sistema externo “comprometido”)

Em outras palavras: RAG transforma documentos em entrada.
Se você não tratar isso como “input não confiável”, a chance de incidente sobe.

O que não funciona (ou funciona pouco)

1. “Colocar uma frase forte no prompt”
   Ajuda, mas não é uma barreira de segurança.
2. Confiar que o modelo vai “se comportar”
   Modelos erram, interpretam mal e podem ser manipulados.
3. Colocar regras de permissão no prompt
   Permissão é uma regra de sistema. Deve ser aplicada no backend (não no texto).

A lógica é parecida com segurança em apps tradicionais: você não confia em input do usuário, valida e aplica autorização no servidor.

Mitigação em camadas (o que costuma dar mais resultado)

Camada 1: Separe instruções de dados (de verdade)

No prompt, deixe claro:

• “instruções” (política do sistema)
• “entrada do usuário”
• “conteúdo recuperado”

E, principalmente, delimite o conteúdo recuperado.

Exemplo conceitual (o formato exato varia):

INSTRUÇÕES DO SISTEMA:
- Siga as políticas abaixo...
- Não execute ações sem validação...

ENTRADA DO USUÁRIO:
<<< ... >>>

CONTEÚDO RECUPERADO (NÃO CONFIÁVEL):
<<< ... >>>

Essa separação reduz a chance de o modelo “achar” que um documento é uma instrução do sistema.

Camada 2: Trate RAG como superfície de ataque

Medidas práticas:

• indexar apenas fontes confiáveis
• bloquear arquivos “abertos” que qualquer pessoa pode editar sem revisão
• aplicar detecção de conteúdo suspeito (palavras‑chave, padrões de jailbreak)
• manter trilha: documento → chunk → resposta

Complemento: Dados sensíveis em RAG.

Camada 3: Reduza agência (menos ferramentas, menos permissão)

Quando você dá ferramentas para o modelo (tool calling), você está dando agência.

A OWASP também trata “agência excessiva” como risco relevante (quando o sistema permite ações demais com autonomia demais).

Regras que ajudam:

• ferramenta só faz uma coisa (não crie “executar qualquer comando”)
• permissões mínimas (read‑only quando possível)
• ações de alto impacto exigem confirmação humana (human‑in‑the‑loop)

Camada 4: Valide a saída antes de usar

Saída de LLM não é “código seguro”.

Se o modelo produz:

• JSON para chamar uma API
• uma query
• HTML/Markdown que vai ser renderizado
• texto que vai para outro sistema

… você precisa validar e sanitizar.

Validações comuns:

• schema rígido (campos, tipos, enums)
• limites de tamanho
• allowlist de ações
• encoding/escape antes de renderizar

Camada 5: Observabilidade e resposta a incidentes

Sem logs e métricas, prompt injection vira “boato”.

Logue:

• tool calls e parâmetros (com redaction quando houver PII)
• documentos/chunks usados (IDs)
• eventos de bloqueio (por política)
• taxa de tentativas suspeitas

E trate como qualquer risco operacional:

• alertas
• playbook de incidentes
• rollback rápido de prompt/modelo/configuração

Se você quer estruturar isso como disciplina, veja: LLMOps: métricas e operação.

Um checklist objetivo para reduzir risco

• Delimitação clara entre instruções, usuário e contexto recuperado
• Conteúdo do RAG tratado como não confiável (inclui validação/filtragem)
• Ferramentas com função específica (evitar “open‑ended tools”)
• Permissões mínimas por ferramenta e por usuário
• Confirmação humana para ações críticas
• Validação de saída (schema, allowlist, tamanho, sanitização)
• Rate limit e limites por usuário (custo e abuso)
• Logs de tool calls, fontes recuperadas e bloqueios por política
• Testes de regressão cobrindo tentativas de jailbreak e casos adversariais

Referências para aprofundar

• OWASP Top 10 for LLM Applications
• OWASP LLM Top 10 2025 (GenAI Security Project)
• LLM06: Excessive Agency (OWASP GenAI)