Resumo Técnico: Contenção sobre Detecção para Defesa contra Injeção de Prompt

Declaração do Problema

A injeção de prompt representa uma vulnerabilidade crítica em sistemas de LLM (Large Language Model) agentes, onde o conteúdo adversário incorporado na entrada do usuário sobrepõe as restrições do sistema, levando à exfiltração de dados, escalonamento de privilégios ou execução de código não autorizada. Os sistemas de produção atuais, particularmente aqueles que se integram a datastores sensíveis e sandboxes de execução de código, dependem fortemente de defesas baseadas em detecção (filtragem de palavras-chave, classificadores aprendidos, análise de perplexidade).

Os autores argumentam que o paradigma de detecção sofre de uma falha fundamental: ele tenta resolver um problema de classificação semântica (distinguir instruções maliciosas de dados legítimos) que é inerentemente ambíguo na linguagem natural. Essa abordagem cria um trade-off inevitável entre precisão e latência. Classificadores de alta precisão introduzem atrasos de inferência e exigem retreinamento contínuo, enquanto mesmo detectores altamente precisos (ex: 99%) falham porque o atacante só precisa de um sucesso para comprometer o sistema. Além disso, mecanismos de detecção frequentemente produzem falsos positivos, rejeitando consultas legítimas de usuários que contêm frases de natureza instrucional.

Metodologia: A Arquitetura de Contenção

O artigo propõe uma mudança da detecção para a contenção. Em vez de tentar identificar e rejeitar a entrada maliciosa, o sistema a torna estruturalmente inerte ao impor uma fronteira criptográfica entre instruções e dados. Isso é alcançado através de uma arquitetura de defesa composta de quatro camadas:

1. Geração de Token Criptográfico Efêmero:
   Ao iniciar o container, um token criptograficamente seguro ($\tau$) é gerado com 256 bits de entropia. Este token é codificado como uma string base64 segura para URL (43 caracteres). Crucialmente, $\tau$ nunca é persistido em disco, logs ou variáveis de ambiente e é rotacionado ao reiniciar o container, garantindo o sigilo direto (forward secrecy).

2. Canonização de Entrada:
   Antes do encapsulamento, a entrada do usuário passa por uma canonização para eliminar vetores de bypass baseados em codificação. Este processo remove caracteres de controle Unicode (categorias Cc) e separadores específicos de linha/parágrafo (Zl/Zp, ex: U+2028, U+2029) que podem ser interpretados de forma diferente por tokenizadores versus lógica de validação. Isso garante que a entrada seja normalizada antes da aplicação da fronteira.

3. Encapsulamento de Envelope Autenticado por Token:
   A entrada canonizada é envolvida em um envelope semelhante ao XML: <untrusted_input id="{token}">...</untrusted_input>.

   • Validação no Lado do Servidor: Uma verificação de segurança crítica ocorre antes do encapsulamento. O sistema rejeita qualquer entrada que já contenha o token $\tau$ ou a estrutura da tag de envelope. Isso evita que um atacante feche prematuramente a tag do envelope para injetar instruções fora da fronteira.
   • Garantia Determinística: A fronteira é criptograficamente imprevisível; um atacante não consegue construir uma tag de fechamento válida sem conhecer $\tau$.

4. Aterramento Comportamental de Prompt (Behavioral Prompt Grounding):
   O prompt do sistema instrui explicitamente o LLM a tratar o conteúdo dentro das tags <untrusted_input> estritamente como dados a serem processados, não como instruções executáveis. O prompt enfatiza que a linguagem de instrução encontrada dentro do envelope deve ser tratada como texto literal. Os autores observam que o uso de frases neutras é preferível a avisos alarmantes para evitar recusas falsas de consultas legítimas.

Principais Contribuições

O artigo apresenta quatro contribuições primárias:

1. Garantia de Segurança Formal: Os autores fornecem uma prova formal (Teorema 1) demonstrando que, sob um modelo de atacante de caixa-preta (sem acesso ao oracle do token de tempo de execução), a probabilidade de um atacante criar um escape de fronteira válido é desprezível ($\le 2^{-256}$).
2. Arquitetura de Defesa Componível: Um sistema de quatro camadas com interfaces formalmente especificadas e isolamento de modo de falha, operando na camada de pré-processamento de entrada, independente do comportamento do modelo.
3. Metodologia de Teste Baseada em Propriedades: Os autores utilizaram o framework Hypothesis para definir 15 invariantes de segurança verificáveis por máquina. Esta abordagem identificou com sucesso três bugs críticos de produção (incluindo um bug de não-idempotência de canonização e um problema de buffer overflow) que os testes convencionais baseados em exemplos não detectaram.
4. Validação Empírica: Uma avaliação abrangente contra 547 padrões adversários extraídos de quatro corpora de ataques estabelecidos (Garak, OWASP LLM Top 10, HarmBench e um conjunto multilíngue customizado).

Resultados

A defesa foi avaliada em um sistema agente de produção que atende cerca de 200 analistas com acesso a bancos de dados, interpretadores de código e bases de conhecimento RAG.

• Taxa de Contenção: O sistema alcançou uma taxa de contenção sintática de 94,3%. Nesses casos, a entrada adversária foi encapsulada com sucesso, e o modelo a tratou como dado.
• Falhas Residuais: A taxa de falha de 5,7% consistiu inteiramente de jailbreaks semânticos de nível de modelo. Nestes casos, a entrada estava sintaticamente contida no envelope, mas o modelo, ainda assim, seguiu as instruções injetadas (ex: via reestruturação cognitiva ou sufixos adversários). Os autores classificam estes como ortogonais à defesa de camada de entrada.
• Falsos Positivos: A defesa produziu 0% de falsos positivos. Como o sistema nunca rejeita a entrada com base no conteúdo (apenas a encapsula), as consultas legítimas contendo frases de instrução foram processadas corretamente.
• Latência: O overhead de tempo de execução foi medido em <0,5ms por requisição, superando significativamente os classificadores aprendidos (180ms) e evitando o inchaço de tokens das defesas do tipo "sanduíche".
• Descoberta de Bugs: Testes baseados em propriedades revelaram falhas críticas, incluindo um problema de não-idempotência de canonização onde caracteres Unicode específicos podiam burlar a validação em passagens repetidas, e um erro de buffer de log que descartava os eventos mais recentes (forensemente relevantes) sob carga.

Significância e Alegações

O artigo alega que a abordagem de contenção altera fundamentalmente o objetivo de segurança para LLMs agentes. Ao mudar da classificação semântica probabilística para a imposição de fronteiras sintáticas determinísticas, a defesa elimina o trade-off entre precisão e latência inerente aos sistemas baseados em detecção.

Os autores enfatizam que, embora a camada de contenção forneça uma fundação criptograficamente sólida que impede o escape estrutural, ela não resolve o problema dos jailbreaks de nível de modelo. A taxa de falha residual de 5,7% representa o limite da defesa de camada de entrada; abordar isso requer salvaguardas complementares de nível de modelo (treinamento de segurança, modelos de guardrail). No entanto, a camada de contenção garante que a fronteira de entrada seja imforgeável, permitindo que defesas de nível superior operem sobre um substrato seguro.

O trabalho posiciona o teste baseado em propriedades como um padrão essencial para a infraestrutura de segurança de LLM, demonstrando sua superioridade na descoberta de vulnerabilidades de casos extremos que os testes baseados em exemplos negligenciam. O harness de avaliação e as especificações de propriedades são liberados como código aberto para facilitar a reprodutibilidade.