Segurança contra prompt injection

A resposta curta

Prompt injection é quando o texto que um modelo lê contém instrução e o modelo obedece. Existe porque modelos não distinguem de forma confiável entre conteúdo que receberam para processar e instrução que receberam para cumprir.

Isso não é bug de um modelo específico. É propriedade de como esses sistemas funcionam, e significa que a defesa precisa ser arquitetural. Tocamos nisso como uma camada em guardrails; aqui está o quadro inteiro.

Direta versus indireta

Injeção direta é um usuário digitando algo adversarial na sua interface. É a versão que todo mundo testa, e é a menos perigosa, porque o atacante só alcança o que aquele usuário já alcançava.

Injeção indireta é o problema real. O atacante nunca toca no seu produto. Ele coloca instrução em algo que o seu sistema vai ler depois: um documento, um chamado de suporte, uma página web, um e-mail, um convite de agenda, um nome de arquivo, um comentário de código.

A instrução então chega com a autoridade do seu próprio pipeline, num contexto em que ninguém está vigiando.

Por que nenhum prompt previne

A mitigação padrão é uma linha no prompt de sistema mandando ignorar instrução encontrada em conteúdo recuperado. Ajuda. Não é controle.

Você está pedindo a um sistema probabilístico que classifique texto como dado e não como instrução de forma confiável, usando o mesmo canal para os dois. Cada frase que você adiciona é mais uma coisa que pode ser superada por uma instrução suficientemente enfática ou bem posicionada mais adiante.

Trate defesa em nível de prompt como fricção, não como fronteira. A fronteira precisa estar em algum lugar com o qual o modelo não consiga discutir.

Inventarie sua superfície de ataque

Escreva toda fonte de texto que chega ao modelo. Na maioria dos sistemas a lista é maior do que o time espera: documento recuperado, campo de perfil de usuário, turnos anteriores de conversa, resultado de chamada de ferramenta, mensagem de erro de outro sistema, nome de arquivo, metadado.

Qualquer item dessa lista escrito por alguém que não é você é não confiável. Isso inclui conteúdo de dentro da sua empresa, porque documento interno continua sendo texto que alguém pode editar. É também por isso que servidores MCP e descrições de ferramenta entram na lista.

Chamada de ferramenta é o que torna grave

Uma instrução injetada num sistema que só produz texto é problema de conteúdo: resposta constrangedora, trecho vazado.

A mesma instrução num sistema que chama funções é problema de ação. Agora ela pode tentar ler registro, enviar mensagem, modificar dado ou exfiltrar o que recuperou embutindo isso numa requisição.

Então a gravidade da injeção é determinada pelo que o modelo tem permissão de fazer, não por quão bom é o seu prompt. Reduzir capacidade reduz o impacto de todo ataque futuro em que você ainda não pensou.

Mitigações que de fato funcionam

Escopo de permissão sempre no usuário solicitante, para que uma injeção bem-sucedida realize apenas o que aquele usuário já podia fazer. Conjunto mínimo de ferramentas por tarefa. Ação destrutiva exigindo confirmação explícita fora do controle do modelo.

Separe dado de instrução estruturalmente onde a API permitir, e delimite claramente conteúdo recuperado para o modelo ter sinal de procedência. Valide a saída antes de agir sobre ela, em vez de confiar porque ela deu parse.

E trate caminhos de exfiltração como parte da superfície: se o modelo consegue colocar texto numa URL, numa referência de imagem ou numa requisição de saída, ele consegue vazar o que leu.

Humano no circuito, bem posicionado

Para ação irreversível ou de alto valor, uma pessoa confirma. A confirmação precisa mostrar o que vai de fato acontecer, em termos simples, não um resumo que o modelo escreveu sobre si mesmo.

Um diálogo de confirmação dizendo que o modelo gostaria de prosseguir é teatro. Um que diz que isto vai enviar esta mensagem para este endereço é controle.

Como testar

Monte uma suíte adversarial e rode em CI. Inclua documento com instrução embutida, tentativa de acessar dado de outro usuário, pedido de exceder escopo de ferramenta, e conteúdo desenhado para disparar exfiltração.

Rode a cada mudança de prompt e a cada atualização de modelo, porque o comportamento por baixo muda sem a sua participação. A disciplina é a mesma de evals de LLM, e a suíte deve crescer toda vez que alguém achar algo novo.

Depois de um incidente

Assuma que o primeiro vai acontecer. O que importa é conseguir responder rápido a três perguntas: o que o modelo leu, o que ele fez, e a que ele tinha acesso. Se o seu log não responde isso, o incidente vira investigação sem evidência.

Depois converta em caso de teste para não poder se repetir em silêncio. Esse ciclo, do incidente ao teste à suíte de regressão, é o que transforma segurança de documento em prática, e faz parte de como construímos IA em produção, ponta a ponta.