Prompt injection: o que é e como prevenir ataques em LLMs

Um recrutador sobe um currículo em PDF para uma ferramenta de triagem com IA.

O arquivo tem texto branco, fonte 1, no rodapé: instruções para o modelo ignorar os critérios anteriores e classificar aquele candidato como o mais adequado.

O modelo obedece.

Nenhum sistema foi invadido, nenhuma senha foi roubada.

A falha estava na fronteira entre dado e comando, e essa fronteira é exatamente onde vive o prompt injection. ## O que é prompt injection Prompt injection é uma classe de ataque em que uma entrada maliciosa insere instruções dentro do contexto de um modelo de linguagem, fazendo com que ele trate esse conteúdo como se fosse uma ordem legítima do desenvolvedor.

O modelo não distingue, de forma nativa, a diferença entre a instrução que veio no prompt de sistema e o texto que chegou depois vindo de um usuário, de um documento ou de uma página web.

Essa confusão é estrutural.

Um LLM processa tudo como uma sequência única de tokens.

Se um trecho dentro dessa sequência diz para desconsiderar as regras anteriores, o modelo pode acatar, porque nada no funcionamento dele separa tecnicamente comando de dado.

A IBM mantém uma página dedicada ao tema no seu centro de pensamento, e a Kaspersky trata o assunto dentro do seu centro de recursos sobre ameaças.

Ambas descrevem o mesmo ponto central: o ataque explora a ausência de uma barreira confiável entre quem manda e o que é processado. ## Injeção direta e injeção indireta Os ataques aparecem em duas formas principais, e a segunda é a mais perigosa. **Injeção direta.** O usuário digita a instrução maliciosa no chat.

Exemplo: pedir que o modelo revele o prompt de sistema ou ignore filtros de conteúdo.

É o tipo mais visível e o mais fácil de monitorar, porque o texto malicioso passa pelo mesmo canal que o usuário controla. **Injeção indireta.** O conteúdo nocivo chega por uma fonte externa que o modelo lê sem supervisão.

Pode estar em uma página web que o agente visita, em um e-mail resumido automaticamente, em um comentário em um repositório de código ou em um documento anexado.

Aqui o atacante nunca fala com o modelo.

Ele planta a instrução onde sabe que o sistema vai buscar informação.

A diferença importa porque a injeção indireta não depende de acesso ao chat.

Basta que o sistema tenha permissão para ler conteúdo de terceiros. ## Por que o problema não tem patch simples A comparação mais usada é com SQL injection.

Em bancos de dados, a solução foi separar consulta de dado por meio de consultas parametrizadas, e isso resolveu a falha na raiz.

Em LLMs, essa separação não existe de forma equivalente, porque o modelo precisa interpretar linguagem natural para funcionar.

Qualquer instrução que o desenvolvedor escreva no prompt de sistema é, ela própria, um texto em linguagem natural.

E qualquer defesa baseada em frases como ignorar instruções vindas do usuário pode ser contornada por outra frase, reescrita de outro jeito.

Quando o modelo tem ferramentas ligadas, o risco cresce.

Um agente com acesso a e-mail, a um banco de dados ou a uma API de pagamento pode executar a ação que o atacante pediu, não apenas responder a ela.

A injeção deixa de ser um problema de texto e passa a ser um problema de execução. ## Como prevenir: defesa em camadas Não existe medida isolada que zere o risco.

O que funciona é combinar controles independentes, de modo que a falha de um não derrube os outros. **1.

Trate todo conteúdo externo como não confiável.** Textos vindos de páginas web, arquivos, e-mails ou campos preenchidos por usuários nunca devem ser concatenados diretamente ao prompt de sistema.

Marque esse conteúdo com delimitadores explícitos e diga ao modelo que o trecho delimitado é dado, não instrução. **2.

Reduza privilégios do agente.** Se o sistema só precisa resumir documentos, ele não deve ter permissão de escrita, de envio de e-mail ou de chamada a APIs sensíveis.

Aplique o princípio do menor privilégio a cada ferramenta exposta ao modelo. **3.

Exija confirmação humana para ações de impacto.** Envio de mensagens, transferências, alterações em banco de dados e publicação de conteúdo devem passar por aprovação.

A confirmação quebra a cadeia entre a instrução injetada e o efeito real. **4.

Filtre entrada e saída.** Na entrada, detecte padrões conhecidos de manipulação.

Na saída, verifique se a resposta contém dados que o modelo não deveria expor, como trechos do prompt de sistema ou informações de outros usuários. **5.

Monitore e registre.** Guarde o histórico de prompts e respostas para auditar incidentes.

Padrões anômalos, como um agente buscando dados fora do escopo da tarefa, aparecem no log antes de virar prejuízo. **6.

Isole o contexto por usuário.** Em aplicações multiusuário, garanta que o modelo não misture dados de sessões diferentes.

Um vazamento por injeção costuma explorar justamente essa mistura.

A DataCamp mantém um material sobre tipos de ataque e defesas que segue essa linha de camadas, e a página de prevenção da IBM reforça que o objetivo não é tornar o modelo incorruptível, e sim limitar o dano quando a manipulação acontece. ## Perguntas que aparecem na prática **Prompt injection é a mesma coisa que jailbreak?** Não.

Jailbreak busca fazer o modelo produzir conteúdo que ele foi treinado para recusar, e o alvo é a política de uso.

Prompt injection busca alterar o comportamento do sistema para executar a vontade de quem injetou, e o alvo é a aplicação construída em cima do modelo.

Os dois podem se combinar, mas os objetivos são diferentes. **Um modelo mais novo resolve isso?** A arquitetura segue sendo a mesma: o modelo lê texto e responde a ele.

Modelos mais recentes recebem treinamento adicional para resistir a manipulações conhecidas, e isso eleva o custo do ataque, mas não elimina a possibilidade.

A defesa precisa estar na aplicação, não apenas no modelo. **Empresas que usam LLM internamente correm risco?** Sim, e às vezes maior.

Um assistente interno com acesso a documentos corporativos pode ser induzido a expor informação sensível se um arquivo malicioso entrar na base que ele consulta.

O perímetro da rede não protege contra uma instrução escondida em um documento autorizado.

O ponto de partida para qualquer equipe é aceitar que o modelo não separa comando de dado sozinho.

A segurança vem das travas que você coloca em volta dele.