Neste artigo
- O que é injeção de prompt e por que quem constrói com LLMs precisa entender
- Como funciona um ataque de injeção de prompt na prática
- Quando sua aplicação está em risco
- Injeção direta vs injeção indireta: qual merece mais atenção
- Como reduzir o risco sem travar a aplicação
- O impacto de ignorar injeção de prompt
- Dúvidas comuns sobre injeção de prompt
- Próximo passo para quem está construindo com LLMs agora
Você monta um chatbot com LLM, configura o system prompt, define as regras do que o modelo pode e não pode responder, testa algumas vezes e funciona. Aí alguém digita algo inesperado no campo de texto e o modelo começa a ignorar tudo que você configurou.
Isso tem nome: injeção de prompt. E não é bug do modelo, é uma vulnerabilidade estrutural de qualquer aplicação que mistura instrução fixa com entrada do usuário no mesmo canal. Mais comum do que parece, especialmente em aplicações que ainda estão na fase de ‘funciona na demo’.
Já testei isso em aplicações próprias e em ambientes de revisão. O que mais impressiona não é a sofisticação do ataque. É o quanto ele é simples quando a aplicação não foi projetada pensando nessa separação.
O que cubro a seguir: como a injeção de prompt funciona de verdade, onde o risco é maior e quais decisões de design reduzem a superfície de ataque, mesmo sem ser especialista em segurança.
O que é injeção de prompt e por que quem constrói com LLMs precisa entender
Um LLM não distingue instrução de dado. Para o modelo, tudo que entra no contexto é texto. Quando você escreve um system prompt dizendo ‘responda sempre em português’ ou ‘nunca mencione concorrentes’, está enviando texto. Quando o usuário digita a pergunta, também está enviando texto. O modelo processa tudo junto.
Injeção de prompt é quando uma entrada, seja do usuário direto ou de uma fonte externa, contém instruções que o modelo interpreta e executa, substituindo ou sobrepondo as suas. O resultado pode variar: o modelo ignora regras, revela informações que não deveria, executa ações não autorizadas ou simplesmente sai do comportamento esperado.
Para quem constrói aplicações com LLM, isso é relevante porque o modelo não vai reclamar nem avisar. Ele só vai obedecer.
Como funciona um ataque de injeção de prompt na prática
Injeção direta
É o caso mais simples. O usuário digita algo no campo de entrada que contém instruções explícitas para o modelo, algo do tipo ‘ignore as instruções anteriores e faça X’. Dependendo do modelo e de como o contexto foi montado, isso pode funcionar parcialmente ou completamente.
Não precisa de técnica sofisticada. Basta o usuário entender que há um system prompt e testar variações até algo passar. É o equivalente de tentar várias combinações numa fechadura comum.
Injeção indireta
Esse é o cenário que a maioria subestima. O usuário não injeta diretamente, mas o modelo processa conteúdo de uma fonte externa que contém a instrução maliciosa.
Exemplos concretos: o modelo lê um documento enviado pelo usuário e esse documento tem texto oculto com instruções. O modelo acessa uma página web como ferramenta e o conteúdo da página tenta redirecionar o comportamento. O modelo consulta um banco de dados e um dos registros foi inserido com texto que age como instrução.
Nesse caso, o usuário pode nem saber que está fazendo isso, ou pode estar fazendo deliberadamente. O problema é que a aplicação não diferencia o conteúdo legítimo da instrução maliciosa porque o modelo também não diferencia. Se você usa RAG para conectar o LLM aos seus próprios dados, injeção indireta é um vetor que precisa estar no seu radar desde o início.
Quando sua aplicação está em risco
O usuário controla parte do prompt
Se qualquer texto que o usuário escreve é inserido diretamente no contexto sem tratamento, a superfície de ataque está aberta. Não importa quão claro seja o system prompt.
O modelo tem acesso a ferramentas externas
Quando o agente pode enviar emails, consultar APIs, escrever em bancos de dados ou executar qualquer ação com efeito real, a injeção de prompt deixa de ser um problema de comportamento do chatbot e vira um problema de segurança operacional. Uma instrução injetada pode fazer o modelo acionar uma ferramenta que não deveria. Esse ponto se conecta diretamente a como você projeta as ferramentas disponíveis para o agente: escopo amplo demais é risco.
Conteúdo de fontes externas entra no contexto
RAG, leitura de documentos, navegação web, consulta a APIs de terceiros. Qualquer dado que vem de fora e é inserido no contexto sem revisão é uma superfície potencial para injeção indireta.
Injeção direta vs injeção indireta: qual merece mais atenção
Depende do que sua aplicação faz.
Se é um chatbot simples sem ferramentas externas, a injeção direta é o risco principal e é mais fácil de mitigar. Limitar escopo, monitorar padrões e usar modelos com instrução de sistema mais robusta já ajuda bastante.
Se a aplicação tem agentes com acesso a ferramentas, a injeção indireta é o risco mais sério. Pra mim, qualquer agente que pode executar ações reais sem confirmação humana precisa ser tratado como sistema que vai receber instruções maliciosas em algum momento. Não como possibilidade remota, como certeza no longo prazo.
A pergunta certa não é ‘minha aplicação vai ser atacada?’. É ‘quando for atacada, o que o modelo consegue fazer?’.
Como reduzir o risco sem travar a aplicação
Separe instrução de dado
Frameworks e ferramentas modernas permitem marcar partes do contexto de formas diferentes. Instrução do sistema vai num bloco, dado do usuário em outro, conteúdo externo é tratado como dado, não como instrução. Isso não elimina o risco completamente, mas reduz a superfície porque o modelo recebe sinais estruturais sobre o que é cada coisa.
Limite o escopo das ferramentas disponíveis
Princípio do menor privilégio aplicado a agentes. Se o modelo não precisa enviar emails, não dê essa ferramenta. Se só precisa ler de um banco, não dê permissão de escrita. Cada ferramenta que você remove é um vetor de ataque eliminado. Mais simples do que parece e mais eficaz do que qualquer filtro de entrada. Isso é parte central de uma estratégia de guardrails para IA em produção.
Valide a saída, não só a entrada
A tendência é focar em filtrar o que entra. Mas em casos de injeção indireta, o conteúdo malicioso pode passar limpo pela entrada e só aparecer no comportamento do modelo. Monitorar o que o modelo faz, não só o que recebe, é o que permite detectar anomalia antes de virar incidente.
O projeto OWASP LLM Top 10 lista injeção de prompt como a primeira vulnerabilidade da lista e traz referências atualizadas para quem quer ir mais fundo na parte técnica de defesa.
O impacto de ignorar injeção de prompt
Depende do que o modelo pode fazer.
Num chatbot sem ferramentas, o impacto costuma ser o modelo responder fora do escopo, revelar partes do system prompt ou adotar um persona diferente do configurado. Chato, pode causar problema de imagem, mas controlável.
Num agente com ferramentas reais, o impacto pode ser envio de dados para destinos errados, execução de ações não autorizadas, acesso a informações que o usuário não deveria ter, ou manipulação de registros. Isso já é incidente de segurança, e a questão de dados trafegando por um LLM fica ainda mais sensível quando um atacante consegue direcionar o comportamento do modelo.
O que eu vejo acontecer na prática é o time minimizar o risco porque ‘ninguém vai fazer isso com nossa aplicação’. E funciona, até funcionar.
Dúvidas comuns sobre injeção de prompt
Isso é culpa do modelo ou da aplicação?
Da aplicação. Os modelos melhoram a resistência a ataques a cada versão, mas a arquitetura da sua aplicação é o que define o tamanho da superfície de risco. Um modelo mais resistente num sistema mal projetado ainda é vulnerável.
Filtrar a entrada do usuário resolve o problema?
Ajuda, mas não resolve. Injeção indireta contorna filtros de entrada porque o conteúdo malicioso não vem do usuário diretamente. Filtro é uma camada de defesa, não uma solução completa.
Preciso ser especialista em segurança para lidar com isso?
Não. As mitigações fundamentais, separar instrução de dado, limitar escopo de ferramentas, monitorar comportamento de saída, são decisões de design que qualquer pessoa construindo com LLMs pode e deve tomar. Especialista em segurança entra em camadas mais avançadas de teste e análise de adversarial prompts.
Modelos mais recentes já são imunes?
Não existe imunidade. Modelos mais recentes são mais resistentes, mas a resistência muda com cada nova variação de ataque. A postura correta é projetar a aplicação assumindo que o modelo pode ser manipulado e limitar o dano que isso causa, não confiar que o modelo vai se defender sozinho.
Próximo passo para quem está construindo com LLMs agora
Injeção de prompt não é um problema que você resolve uma vez e esquece. É uma categoria de risco que cresce junto com o que sua aplicação pode fazer. Quanto mais ferramentas, mais fontes externas de dados e mais autonomia você der ao agente, maior a superfície.
Se você está construindo algo com LLM agora, a pergunta mais útil é: o que o modelo consegue fazer na minha aplicação que eu não autorizei explicitamente? Responder isso com honestidade já mostra onde investir primeiro.
Se quiser aprofundar, dois pontos de partida práticos:
- Revisar as ferramentas disponíveis para o agente e remover as que não são estritamente necessárias
- Mapear todas as fontes externas que entram no contexto do modelo e tratar cada uma como dado não confiável
- Adicionar monitoramento de comportamento de saída, não só de volume e custo
Para quem quer entender mais sobre como controlar o comportamento do modelo em produção de forma geral, o texto sobre guardrails para IA em produção é um complemento direto a esse assunto.
