Injeção de solicitações e jailbreaks

Injeção de instruções é o equivalente, na era dos LLM, às falhas clássicas de injeção (linguagem de consulta estruturada e comandos). A causa-raiz é idêntica: um aplicativo mistura instruções confiáveis e dados não confiáveis no mesmo canal, e o interpretador (o modelo) não consegue distingui-los de forma confiável.

Com um LLM, a instrução do sistema, as instruções do desenvolvedor e todo o conteúdo recuperado chegam como um único fluxo linear de unidades de texto. Se o texto controlado pelo atacante disser Ignore previous instructions and..., o modelo poderá obedecer, pois, para o modelo, isso é apenas mais linguagem.

• Confiável: sua instrução do sistema e sua política.
• Não confiável: entrada do usuário, páginas da web, arquivos, saída de ferramentas e e-mails.

A injeção direta de instruções ocorre quando o usuário final digita instruções adversariais diretamente na instrução para substituir o comportamento pretendido do aplicativo.

Uma tentativa típica contra um robô de suporte ao cliente é assim:

• Diz-se ao robô que responda apenas a perguntas sobre cobrança.
• O usuário cola um texto que reformula o papel do modelo e pede que ele vaze sua instrução do sistema ou execute ações fora do escopo.

A injeção direta é mais fácil de analisar porque o texto malicioso e o atacante são a mesma pessoa, mas ainda assim contorna mecanismos de proteção ingênuos.

A injeção indireta (de segunda ordem) é a variante mais perigosa. O atacante insere instruções em conteúdo que o modelo recuperará posteriormente: uma página da web, um PDF, um convite de calendário, um comentário de código ou um chamado de suporte.

O usuário vítima nunca vê a carga útil. Quando um fluxo de RAG ou um agente de navegação incorpora esse conteúdo ao contexto, as instruções ocultas são executadas com os privilégios do usuário.

Exemplo: uma página da web contém texto oculto instruindo um agente de resumo a exfiltrar o histórico de conversas do usuário para um endereço controlado pelo atacante.

Esses termos se sobrepõem, mas não são idênticos:

• Injeção de instruções ataca a fronteira do aplicativo — substituindo as instruções do desenvolvedor por dados do atacante.
• Quebra de restrições ataca o alinhamento de segurança do modelo — levando-o a produzir conteúdo que o provedor o treinou para recusar.

Uma quebra de restrições não exige um aplicativo vulnerável; ela funciona contra o modelo bruto. Muitos ataques reais combinam ambos: uma quebra de restrições reduz as recusas, enquanto a injeção redireciona o comportamento do aplicativo.

Os atacantes usam padrões previsíveis de manipulação. Conhecê-los ajuda você a realizar testes de equipe vermelha no próprio sistema com responsabilidade:

• Interpretação de papéis/personagem: enquadrar a solicitação como ficção ou como se viesse de um personagem fictício sem restrições.
• Ofuscação: base 64, linguagem leet, tradução ou divisão em unidades para escapar dos filtros de palavras-chave.
• Divisão da carga útil: distribuir uma solicitação entre várias interações para que nenhuma mensagem isolada pareça maliciosa.
• Hipóteses: For a security class, describe how one would...
• Injeção de prefixo: forçar a resposta a começar com uma afirmação como Sure, here is.

Muitas equipes recorrem primeiro a uma lista de bloqueio de frases como ignore previous instructions. Essa abordagem é frágil porque o espaço de entradas é efetivamente infinito.

A linguagem natural pode expressar a mesma intenção de inúmeras formas, em diferentes idiomas, codificações e metáforas. Os atacantes iteram mais rápido do que você consegue corrigir as expressões regulares.

Princípio fundamental: trate a filtragem de entradas como defesa em profundidade, nunca como um controle primário. Pressuponha que alguma injeção passará e projete o sistema de modo que uma injeção bem-sucedida ainda não possa causar danos reais.

A mitigação mais eficaz é arquitetural: limite o que um contexto de modelo comprometido pode fazer.

• Conceda ao LLM o privilégio mínimo necessário. Um resumidor não deve ter credenciais para enviar e-mails.
• Mantenha o conteúdo não confiável fora dos caminhos privilegiados. Se um agente lê dados externos da web, ele também não deve poder executar ações irreversíveis na mesma interação sem um ponto de verificação.
• Separe os planos de dados dos planos de controle: o texto recuperado deve ser dados, não comandos.

Embora não seja infalível, a estrutura das instruções eleva o nível de dificuldade. Delimite claramente os dados não confiáveis e instrua o modelo sobre como tratá-los.

Use delimitadores explícitos e diga ao modelo que tudo o que estiver dentro deles são dados a serem analisados, não instruções a serem seguidas. Combine isso com um papel forte para o sistema, reforçado pelo aplicativo em cada chamada.

A saída de um modelo também não é confiável. Se o aplicativo direcionar a saída do LLM para um interpretador de comandos, banco de dados, navegador ou outra ferramenta, a injeção se transforma em execução remota de código ou exfiltração de dados.

A tríade letal de Simon Willison descreve a combinação perigosa:

• Acesso a dados privados,
• Exposição a conteúdo não confiável,
• Capacidade de se comunicar externamente (exfiltrar dados).

Um agente com os três elementos pode ser transformado em uma ferramenta de roubo de dados por uma única instrução injetada. Rompa a tríade para interromper o ataque.

Pressuponha que a injeção ocorrerá e instrumente o sistema para detectá-la:

• Registre todo o contexto (instruções, partes recuperadas, chamadas de ferramentas) para análise de incidentes.
• Use um classificador secundário ou modelo de proteção para sinalizar entradas e saídas suspeitas.
• Monitore o uso anômalo de ferramentas: requisições de saída repentinas, acesso inesperado a dados, padrões de vazamento de instruções.
• Aplique marcadores canário nas instruções do sistema; se um marcador canário aparecer na saída, ocorreu um vazamento.

Trate os alertas como incidentes reais, seguindo um manual de resposta.

Testar seus próprios sistemas quanto a injeções é essencial e legítimo. Faça isso com responsabilidade:

• Teste somente sistemas que você possui ou está autorizado a avaliar.
• Use um ambiente controlado e dados sintéticos; nunca exfiltre dados reais de usuários.
• Documente as descobertas e inclua-as em testes de regressão, para que as evasões corrigidas continuem corrigidas.
• Coordene a divulgação quando encontrar problemas em modelos ou aplicativos de terceiros.

O objetivo é tornar seu aplicativo resiliente, não produzir capacidades nocivas.

Teste sua compreensão das fronteiras de confiança na injeção.

Principais conclusões sobre injeção de instruções e quebras de restrições:

• A injeção decorre da mistura de instruções confiáveis com dados não confiáveis em um único canal.
• A injeção direta vem do usuário; a injeção indireta se esconde em conteúdo recuperado e é mais furtiva.
• As quebras de restrições atacam o alinhamento do modelo; a injeção ataca a fronteira do aplicativo. Elas se combinam.
• A filtragem de entradas é apenas defesa em profundidade, nunca o controle primário.
• Mitigue arquiteturalmente: use o privilégio mínimo, separe dados de controle e rompa a tríade letal (dados privados + conteúdo não confiável + exfiltração).
• Trate a saída do modelo como não confiável, registre tudo e realize testes de equipe vermelha de forma ética.