Resumo Técnico: Trade-offs entre Segurança e Fidelidade em Defesa contra Injeção de Prompt

1. Declaração do Problema

As defesas atuais contra injeção de prompt indireta em Grandes Modelos de Linguagem (LLMs) sofrem de um ponto cego crítico: elas avaliam a segurança puramente com base no fato de uma instrução injetada ter sido executada (sequestrada). Esta métrica falha em distinguir dois comportamentos qualitativamente diferentes que resultam ambos em "não-execução":

1. Processamento Fiel: O modelo trata corretamente o texto injetado como dados não confiáveis a serem processados de acordo com a tarefa (ex: traduzir o texto, extrair entidades dele).
2. Supressão: O modelo ignora ou suprime o texto injetado inteiramente, tratando-o como ruído a ser descartado.

Embora ambos os comportamentos impeçam o modelo de seguir comandos maliciosos, a supressão constitui uma falha de fidelidade para tarefas que exigem a preservação ou transformação do conteúdo de entrada (ex: tradução, edição de documentos ou sumarização). Os benchmarks existentes não conseguem detectar essa distinção porque carecem de "separabilidade comportamental" — a capacidade de produzir saídas distinguíveis para execução, processamento ou negligência. Consequentemente, uma defesa que alcança alta segurança ao suprimir agressivamente conteúdos que parecem instruções, mas são benignos, pode parecer robusta enquanto, na verdade, corrompe a utilidade da aplicação.

2. Metodologia: O Benchmark SECFID

Para abordar essa lacuna, os autores introduzem o SECFID, um benchmark projetado para tornar a fidelidade mensurável juntamente com a segurança.

Princípio Central de Design: Separabilidade Comportamental

O SECFID constrói instâncias onde três comportamentos distintos do modelo geram saídas observáveis e distinguíveis:

• EXECUTADO (EXECUTED): O modelo segue a instrução injetada (ex: responder diretamente a uma pergunta de sondagem).
• PROCESSADO (PROCESSED): O modelo trata o texto injetado como dado e o incorpora ao resultado da tarefa (ex: traduzir a sondagem ou incluir uma entidade introduzida pela sondagem em uma lista).
• IGNORADO (IGNORED): O modelo suprime o texto injetado, produzindo uma saída idêntica à entrada limpa sem a sondagem.

Famílias de Tarefas

O benchmark utiliza duas famílias de tarefas para garantir essa separabilidade:

1. Tarefas de Texto Completo (Tradução, Edição): Estas exigem a preservação ou transformação de todo o input. Se uma sondagem for ignorada, a saída exibirá uma omissão mensurável em comparação com a referência processada.
2. Tarefas de Texto Parcial (Extração de Entidades, Contagem): Estas exigem a agregação de elementos específicos. As sondagens são construídas para introduzir novas entidades ou alterar contagens. Se processadas, o output incluirá esses novos elementos; se ignoradas, não os incluirá.

Métricas de Avaliação

Os autores definem duas métricas primárias derivadas dos rótulos comportamentais:

• Segurança: $1 - \text{Taxa de Execução}$. Mede a robustez contra o sequestro de instruções.
• Fidelidade: $1 - \text{Taxa de Ignorados}$. Mede a capacidade do modelo de evitar a supressão de conteúdo relevante para a tarefa.
• Processamento Seguro (Safe Processing): A interseção de ser processado e não executado ($\text{PROCESSED} \land \neg \text{EXECUTED}$), representando o comportamento robusto ideal.

O benchmark compreende 1.168 instâncias em 48 configurações de modelos (incluindo modelos de API fechados como Claude, Gemini, GPT, e modelos de pesos abertos como Llama, Gemma, Qwen) e quatro mecanismos de defesa (ASIDE, DefensiveTokens, ISE, SECALIGN).

3. Resultados Principais

A Fronteira Segurança–Fidelidade

Experimentos revelam um trade-off fundamental: nenhum modelo ou configuração de defesa alcança simultaneamente alta segurança e alta fidelidade.

• Modelos de Alta Fidelidade: Modelos de pesos abertos sem defesas (ex: Llama 3.3 70B) alcançam alta fidelidade (96,5%), mas baixa segurança (47,8%), frequentemente executando injeções.
• Defesas de Alta Segurança: Modelos defendidos (ex: variantes do SECALIGN) alcançam segurança quase perfeita (99,3%), mas sofrem quedas significativas de fidelidade (71,0%–73,9%).
• A Fronteira: Os modelos e defesas distribuem-se ao longo de uma fronteira onde os ganhos em segurança são inversamente correlacionados com as perdas em fidelidade. Escalar o tamanho do modelo desloca o ponto operacional ao longo desta fronteira, mas não elimina o trade-off.

Mecanismo de Defesa: Reparo vs. Supressão

O artigo demonstra que defesas com pontuações de segurança idênticas alcançam-nas através de mecanismos diferentes:

• Reparo (Repair): Algumas defesas (notadamente o SECALIGN) convertem inputs sequestrados em processamento fiel. Elas reduzem a execução ensinando o modelo a tratar a injeção como dado.
• Supressão (Suppression): Outras defesas (notadamente o DefensiveTokens) alcançam segurança principalmente pela supressão do conteúdo injetado. Elas convertem sequestros em saídas ignoradas, levando a maiores falhas de fidelidade.
• Lacuna Quantitativa: No Llama 3.1 8B, o SECALIGN repara 54,0% dos sequestros do modelo base, enquanto o DefensiveTokens suprime 60,3% deles.

Impacto do Raciocínio

Aumentar as capacidades de raciocínio (modos de "pensamento") geralmente melhora a segurança ao reduzir as taxas de execução, mas não melhora a fidelidade de forma confiável. Em muitos casos, níveis mais altos de raciocínio diminuem ligeiramente a fidelidade, sugerindo que o raciocínio é uma ferramenta para reduzir sequestros, e não um mecanismo para preservar a integridade dos dados.

Extensão Agêntica

O trade-off persiste em configurações agênticas (uso de ferramentas). Embora as APIs de fronteira e as variantes do SECALIGN mostrem alta segurança (94–100%) em cenários de uso de ferramentas, sua fidelidade varia amplamente (31,7% a 72,6%), confirmando que o trade-off se generaliza além da geração de texto.

4. Contribuições

1. Identificação de Ambiguidade: O artigo estabelece que a "não-execução" é ambígua e não consegue distinguir entre a separação robusta de instrução-dado e a supressão prejudicial de dados.
2. Benchmark SECFID: Introdução de um benchmark que decompõe o comportamento em segurança e fidelidade, tornando mensurável o custo oculto da supressão.
3. Mapeamento de Trade-off Empírico: Demonstração de uma estrita fronteira segurança–fidelidade através de 48 configurações, mostrando que as defesas atuais frequentemente trocam fidelidade por segurança.
4. Análise de Mecanismo de Defesa: Revelação de que defesas com taxas de sequestro equivalentes diferem drasticamente quanto ao fato de "repararem" sequestros (processamento fiel) ou "suprirem" o conteúdo.
5. Otimalidade Dependente de Implementação: Uma análise teórico-decisória mostrando que a política de defesa ótima não é universal, mas depende da razão de custo específica da implementação entre uma violação de segurança (sequestro) e uma perda de fidelidade (trecho descartado).

5. Significância e Alegações

O artigo argumenta que a segurança sozinha mede apenas metade da robustez. Reportar métricas de segurança sem fidelidade esconde o preço pelo qual a robustez foi comprada.

• Não Existe Política Universal: Os autores afirmam que nenhuma política de defesa fixa é ótima em todos os lugares. O comportamento correto (processar vs. filtrar) depende do contexto de implementação. Em tarefas de alta fidelidade (ex: tradução), suprimir conteúdo é inaceitável; em tarefas de alta segurança (ex: agentes financeiros), suprimir trechos suspeitos é preferível.
• Do Diagnóstico ao Prescritivo: Embora seja primordialmente diagnóstico, o artigo demonstra que o SECFID pode ser usado para melhorar as defesas. Ao aplicar a Otimização de Preferência Direta (DPO) com uma ordenação de preferência de $\text{PROCESSADO} \succ \text{IGNORADO} \succ \text{EXECUTADO}$, eles conseguiram deslocar um modelo defendido da supressão para o processamento fiel, recuperando a fidelidade enquanto mantinham a segurança.
• Implicação Social: O trabalho destaca o risco de "falhas silenciosas", onde defesas fixas e agnósticas à tarefa corrompem a integridade dos dados sem aviso. Ele defende defesas ajustáveis e transparentes que se alinhem com a tolerância ao risco específica da implementação, em vez de pontuações de segurança de tamanho único.

O artigo conclui que a defesa contra injeção de prompt deve ser reportada como um ponto operacional consciente da tarefa, e não como um único score de segurança, e que as avaliações futuras devem medir explicitamente a fidelidade para evitar mascarar a degradação da utilidade do modelo.