Resumo Técnico: Defendendo contra Injeção de Prompt com o DataFilter

1. Declaração do Problema

O artigo aborda a vulnerabilidade crítica de segurança de injeção de prompt em agentes de Grandes Modelos de Linguagem (LLMs). À medida que os LLMs são cada vez mais implantados para automatizar tarefas (ex: navegação na web, chamada de ferramentas) e interagir com dados externos não confiáveis (documentos, e-mails, saídas de ferramentas), atacantes podem injetar instruções maliciosas nesses dados. Essas injeções substituem o prompt original confiável do usuário, redirecionando o agente para realizar ações indesejadas e potencialmente prejudiciais, como vazamento de dados ou execução de malware.

As defesas existentes sofrem de trade-offs significativos:

• Defesas ao nível do sistema: Exigem um redesenho de sistema não trivial e frequentemente resultam em perda substancial de utilidade porque restringem o controle de fluxo de dados.
• Defesas ao nível do modelo (Fine-tuning): Requerem acesso aos pesos do modelo, tornando-as inaplicáveis a modelos proprietários de caixa-preta (black-box).
• Defesas baseadas em detecção: Frequentemente incorrem em altas taxas de falsos positivos, levando à degradação da utilidade ao rejeitar entradas benignas.
• Defesas baseadas em prompt: Geralmente oferecem segurança fraca, com taxas de sucesso de ataque (ASR) muitas vezes excedendo 40%.

Os autores identificam uma lacuna para uma defesa que seja agnóstica ao modelo (funciona em qualquer backend, incluindo proprietários), preservadora de utilidade e altamente segura sem exigir redesenho do sistema.

2. Metodologia: DataFilter

Os autores propõem o DataFilter, um mecanismo de defesa agnóstico ao modelo e aplicado em tempo de teste (test-time). Diferente dos sistemas de detecção que rejeitam entradas inteiras, o DataFilter atua como um filtro que se posiciona entre a fonte de dados não confiável e o LLM de backend.

Mecanismo Central

O DataFilter recebe duas entradas:

1. Instrução Confiável ($u$): O prompt original do usuário.
2. Dados Não Confiáveis ($x$): Os dados externos que podem conter injeções.

A tarefa do filtro é gerar uma versão saneada dos dados ($x_{clean}$) que remova instruções maliciosas enquanto preserva o conteúdo benigno relevante para a instrução confiável. Isso é formulado como um problema de geração de sequência-para-sequência condicional.

Processo de Treinamento (Supervised Fine-Tuning)

O modelo de filtro (baseado no Llama-3.1-8B-Instruct) é treinado via Supervised Fine-Tuning (SFT) em um conjunto de dados customizado construído a partir do conjunto de ajuste de instrução Alpaca. A estratégia de treinamento envolve quatro objetivos de design fundamentais para garantir robustez:

1. Preservação Benigna: O modelo é treinado em amostras sem injeção para aprender que, se os dados forem benignos, eles devem ser gerados sem alterações.
2. Prevenção de Alucinação: Para impedir que o modelo "complete" o texto após deletar uma injeção (um comportamento comum de LLMs), os dados de treinamento incluem amostras onde os dados benignos são truncados. O modelo aprende a gerar os dados truncados exatamente como são, sem gerar novos tokens.
3. Prevenção de Repetição Infinita: Um token especial de fim de sequência (<|end_of_data|>) é introduzido e treinado para garantir que o filtro interrompa a geração imediatamente após os dados limpos, evitando loops infinitos.
4. Generalização Posicional: As injeções são simuladas em posições aleatórias (início, meio, fim) dentro dos dados para garantir que o filtro possa identificar e remover injeções independentemente de sua localização.

O objetivo de treinamento minimiza a log-verossimilhança negativa de gerar os dados limpos reais dado o par de prompt e dados injetados:
$$L(\theta) = -\log p_\theta(x_{clean} | \langle u, x \rangle)$$

Lidar com Dados Estruturados

Para aplicações de agentes onde os dados são estruturados (ex: JSON), o DataFilter analisa a estrutura, filtra recursivamente o conteúdo de texto das chaves e valores, e reconstrói o objeto. Isso evita a geração de JSON sintaticamente inválido.

3. Principais Contribuições

• Uma Nova Arquitetura de Defesa: O DataFilter é a primeira defesa agnóstica ao modelo que combina a segurança de abordagens de nível de sistema com a facilidade de implantação de abordagens de nível de modelo, sem exigir os pesos do modelo de backend.
• Lógica de Filtragem Sofisticada: Ao condicionar o filtro na instrução confiável do usuário, o sistema pode distinguir entre sentenças imperativas que são injeções maliciosas e aquelas que são contexto benigno (ex: listas de "TODO" em e-mails), uma distinção que métodos anteriores tinham dificuldade em fazer.
• Avaliação Abrangente: O artigo avalia a defesa através de múltiplos benchmarks (SEP, InjecAgent, AgentDojo, AlpacaEval2) e contra diversos vetores de ataque (Straightforward, Ignore, Completion, Multi-Turn e Context attacks).

4. Resultados Experimentais

Os autores avaliaram o DataFilter contra baselines incluindo PromptGuard, DataSentinel, Sandwich prompting, Spotlighting, Tool Filter e o trabalho concorrente PromptArmor.

Desempenho de Segurança (Taxa de Sucesso de Ataque - ASR)

• AgentDojo: O DataFilter reduziu o ASR para uma média de 0,4% (máximo de 1,2%) em vários tipos de ataque, superando o PromptArmor (média de 0,7%) e superando significativamente as defesas baseadas em detecção e baseadas em prompt (que frequentemente apresentavam ASR > 20%).
• InjecAgent: O DataFilter alcançou um ASR de 2,0% (Ataque Base) e 0,0% (Ataque Melhorado) no gpt-4o, e 2,1% e 1,2% no Llama-3.1-8B-Instruct.
• SEP (Seguimento de Instrução): O DataFilter manteve um baixo ASR em todos os seis tipos de ataque tanto para o gpt-4o quanto para o Llama-3.1-8B-Instruct. Notavelmente, foi uma das poucas defesas eficazes contra o ataque de Contexto (Context attack), que mimetiza instruções legítimas.
• Ataques Adaptativos: Mesmo sob ataques adaptativos desenhados por humanos e fortes ataques adaptativos baseados em LLM (usando algoritmos genéticos), o DataFilter manteve o menor ASR entre todas as defesas testadas (83% vs. 93% para o PromptArmor no pior cenário de uso de LLM), embora os autores notem que nenhuma defesa é atualmente imune aos ataques adaptativos mais sofisticados.

Desempenho de Utilidade

• AgentDojo: O DataFilter preservou 79,4% da utilidade benigna (apenas uma queda de ~2% em comparação ao modelo sem defesa), enquanto defesas baseadas em detecção como o DataSentinel sofreram severa perda de utilidade (36,6%) devido a falsos positivos.
• AlpacaEval2: O DataFilter manteve pontuações de utilidade comparáveis ao baseline sem defesa (54,1% para o gpt-4o), demonstrando que o processo de filtragem não degrada a qualidade das respostas para tarefas benignas.

Trade-off

Conforme ilustrado nas figuras do artigo, o DataFilter alcança um trade-off Segurança-Utilidade superior, aproximando-se mais da "defesa ideal" (zero ASR com zero queda de utilidade) do que qualquer método anterior.

5. Significância e Alegações

O artigo afirma que o DataFilter oferece uma defesa prática e plug-and-play para proteger LLMs comerciais de caixa-preta contra injeção de prompt. Sua significância reside em:

1. Acessibilidade: Não requer acesso aos pesos do modelo, tornando-o implantável para desenvolvedes de terceiros que utilizam APIs proprietárias.
2. Eficácia: Mitiga com sucesso uma ampla gama de ataques de injeção, incluindo aqueles que são contextualmente relevantes e difíceis de detectar.
3. Preservação de Utilidade: Evita o problema de "recusa excessiva" (over-refusal) comum em sistemas de detecção, garantindo que os agentes permaneçam funcionais para tarefas legítimas.

Os autores reconhecem que, embora o DataFilter seja robusto contra os vetores de ataque atuais, ele ainda pode ser vulnerável aos ataques adaptativos mais sofisticados, uma limitação compartilhada por todas as defesas existentes. No entanto, eles posicionam o DataFilter como uma solução forte e imediata para o curto e médio prazo para proteger agentes de LLM em nível de produção.