The Defense Trilemma: Why Prompt Injection Defense Wrappers Fail?

1. O Problema

O artigo aborda a questão fundamental de segurança em Grandes Modelos de Linguagem (LLMs): é possível construir um "wrapper" (camada de defesa) que elimine completamente todas as vulnerabilidades de injeção de prompt?

A maioria das defesas atuais (classificadores de entrada, filtros de saída, reescrita constitucional) assume implicitamente que sim. Elas operam como uma função $D: X \to X$ que pré-processa a entrada antes de o modelo vê-la, mapeando entradas inseguras para equivalentes seguros, enquanto deixa as entradas seguras inalteradas (preservação de utilidade).

Os autores provam que, sob duas restrições principais:

1. Continuidade: Prompts semelhantes devem gerar reescritas semelhantes (a defesa não pode fazer saltos bruscos).
2. Preservação de Utilidade: Prompts seguros devem passar sem alterações ($D(x) = x$ para $x$ seguro).

A resposta é não. É matematicamente impossível criar uma defesa que seja simultaneamente contínua, que preserve a utilidade e que seja completa (garantir que todas as saídas sejam seguras).

2. Metodologia e Abordagem Teórica

Os autores utilizam uma combinação rigorosa de topologia, análise matemática e verificação formal para estabelecer suas conclusões:

• Estrutura Matemática: O espaço de prompts é modelado como um espaço topológico conexo (onde o "espaço" está em uma peça só). A segurança é definida por uma função de desvio de alinhamento contínua $f: X \to \mathbb{R}$ com um limiar $\tau$.
  • Região Segura ($S_\tau$): $f(x) < \tau$.
  • Região Insegura ($U_\tau$): $f(x) > \tau$.
  • Fronteira ($B_\tau$): $f(x) = \tau$.
• Lógica Topológica: O argumento central baseia-se no fato de que, em um espaço conexo, a região segura é um conjunto aberto, mas não fechado. Uma defesa contínua que fixa todos os pontos seguros deve, por continuidade, fixar também os pontos na fronteira. Isso cria uma contradição se a defesa tentar mapear todos os pontos inseguros para a região segura sem alterar os pontos de fronteira.
• Verificação Formal: Toda a teoria foi mecanicamente verificada usando o assistente de prova Lean 4 com a biblioteca Mathlib. O artefato contém 45 arquivos, cerca de 350 teoremas e zero provas admitidas ("sorry"), garantindo a correção lógica absoluta dos resultados.
• Validação Empírica: Os resultados teóricos foram validados em três LLMs diferentes (Llama-3-8B, GPT-OSS-20B e GPT-5-Mini), mapeando seu comportamento em um espaço de 2D (indireção da consulta e enquadramento de autoridade).

3. Principais Contribuições e Resultados

O artigo estabelece um "Trilema da Defesa": Continuidade, Preservação de Utilidade e Completude não podem coexistir. Os autores detalham três níveis de impossibilidade, sob hipóteses progressivamente mais fortes:

A. Fixação de Fronteira (Boundary Fixation)

• Teorema 4.1: Qualquer defesa contínua e que preserve utilidade em um espaço conexo deve fixar pelo menos um ponto na fronteira de segurança ($z$ onde $f(z) = \tau$).
• Implicação: A defesa não pode remediar todos os prompts de fronteira; pelo menos um deles passará inalterado, mantendo seu nível de risco exato no limiar.

B. Restrição $\epsilon$-Robusta

• Teorema 5.1: Sob regularidade Lipschitz (suavidade da função), a defesa não pode reduzir uniformemente o desvio de alinhamento muito abaixo do limiar $\tau$ perto dos pontos de fronteira fixados.
• Implicação: Existe uma "faixa" positiva de medidas ao redor do ponto fixado onde a defesa é incapaz de garantir segurança profunda. A segurança permanece vulnerável dentro de uma distância $\delta$ do ponto fixo.

C. Região Insegura Persistente

• Teorema 6.3: Sob uma condição de transversalidade (quando a superfície de alinhamento sobe mais rápido do que a defesa consegue puxá-la para baixo), existe um subconjunto de medida positiva de entradas que permanecem estritamente inseguras após a defesa.
• Implicação: Em cenários anisotrópicos (onde o risco aumenta rapidamente em certas direções), a defesa falha em uma região mensurável e não nula, independentemente de quão agressiva seja a reescrita, desde que a utilidade seja preservada.

D. Resultados Discretos e Extensões

• Dilema Discreto: Em conjuntos finitos, uma defesa completa força a não-injetividade (perda de informação/distinção entre prompts), enquanto uma defesa que preserva a informação (injetiva) é incompleta.
• Extensões: Os resultados foram estendidos para interações multi-turno, defesas estocásticas e pipelines não-lineares, mostrando que a impossibilidade persiste nesses cenários também.

4. Significado e Implicações Práticas

O que os teoremas NÃO dizem:

• Não dizem que a defesa é inútil.
• Não se aplicam a alinhamento no tempo de treinamento (RLHF, DPO).
• Não se aplicam a mudanças arquiteturais no modelo.
• Não se aplicam a defesas descontínuas (ex: listas de bloqueio rígidas ou classificadores que rejeitam entradas em vez de reescrevê-las).
• Não se aplicam a sistemas com revisão humana ou filtros de saída.

O que os teoremas dizem para a Engenharia:

O objetivo de engenharia deve mudar de "eliminação total" para "gerenciamento de risco". Os autores propõem quatro diretrizes práticas:

1. Tornar a fronteira rasa: Configurar o limiar $\tau$ de modo que o comportamento na fronteira seja benigno (ex: uma recusa educada em vez de uma violação). Se o ponto fixo na fronteira não causa dano real, o teorema é matematicamente verdadeiro, mas praticamente inofensivo.
2. Reduzir a constante Lipschitz: Suavizar a superfície de alinhamento para estreitar a região de falha persistente, embora isso possa espalhar vulnerabilidades por uma área maior (mas mais monitorável).
3. Reduzir a dimensão efetiva: Restringir a interface de prompts (formatos padronizados, parâmetros limitados) para tornar o espaço de comportamento tratável e reduzir o custo computacional da defesa.
4. Monitorar, não eliminar: Reconhecer que as travessias transversais persistem. Em vez de tentar eliminar a fronteira, implementar monitoramento em tempo de execução para detectar a aproximação da fronteira de segurança.

Conclusão

O artigo fornece uma prova matemática rigorosa de que wrappers contínuos e que preservam utilidade são inerentemente incapazes de garantir segurança completa contra injeção de prompt em espaços de prompts conectados. A "Manifold of Failure" (Variedade da Falha) é uma estrutura geométrica inevitável. A solução não é tentar contornar essa impossibilidade com wrappers mais complexos, mas sim redesenhar os sistemas para tornar as falhas inevitáveis menos danosas, monitoráveis e gerenciáveis.