Resumo Técnico: Twin Agent – Compressão de Resíduo de Contexto para Agentes com Separação de Privilégios

1. Definição do Problema

Agentes de Grandes Modelos de Linguagem (LLMs) operando em ambientes abertos enfrentam riscos de segurança significativos, particularmente ataques de injeção de prompt. Nesses cenários, entradas não confiáveis (ex: documentos recuperados, conteúdo da web, saídas de ferramentas) podem manipular o raciocínio subsequente e o uso de ferramentas do agente, levando a ações não autorizadas ou prejudiciais.

Abordagens existentes de segurança por design tentam mitigar isso separando observações não confiáveis de execução privilegiada (ex: padrões de Dual LLM). No entanto, esses métodos sofrem de duas limitações críticas:

1. Degradação de Utilidade: A separação estrita ou fluxos de trabalho rígidos de "planejamento primeiro" frequentemente falham em preservar a utilidade da tarefa, especialmente em tarefas de longo horizonte e adaptativas (como engenharia de software) que exigem exploração iterativa e feedback dinâmico.
2. Sobrecarga de Engenharia: Muitas soluções exigem extensa engenharia específica para a tarefa, protocolos de comunicação fixos ou tipos de dados rígidos, tornando-as difíceis de adaptar entre tarefas heterogêneas de agentes.

O desafio central é equilibrar segurança (prevenir o fluxo de informação que permite ataques) com utilidade (fornecer informação suficiente para o agente realizar sua tarefa).

2. Metodologia: Twin Agent

Os autores propõem o Twin Agent, um padrão de design de separação de privilégios generalizado inspirado em codificação residual. O insight central é que a comunicação segura é mais eficaz quando é diferencial em vez de absoluta. Em vez de transmitir um resumo sanitizado de todo o contexto não confiável, o sistema transmite apenas a informação residual necessária para a próxima decisão.

Arquitetura

O Twin Agent consiste em dois agentes quase simétricos:

1. Agente de Exploração (Explore Agent):
   • Observa a região total não confiável ($U$) e as especificações de tarefa confiáveis.
   • Não pode executar ações privilegiadas.
   • Seu papel é inspecionar a informação não confiável e extrair "dicas" relevantes para a tarefa.
2. Agente Seguro (Safe Agent):
   • Executa ações privilegiadas (ex: execução de código, acesso ao sistema de arquivos).
   • Não pode observar diretamente a informação não confiável ($U$).
   • Mantém um histórico de interação autoritativo.
   • Recebe apenas uma dica compacta do Agente de Exploração.

Mecanismo: Compressão de Resíduo de Contexto

O sistema opera sob o princípio de que o Agente Seguro já possui o estado atual da tarefa ($I^{(s)}_t$). Portanto, o Agente de Exploração não precisa retransmitir o contexto completo. Em vez disso, ele é condicionado ao estado atual do Agente Seguro e gera uma dica ($H^{(e)}_t$) contendo apenas a informação residual relevante para a tarefa necessária para decidir a próxima ação.

Isso é formalizado como um problema de otimização onde o Agente de Exploração busca uma dica que minimize a discrepância entre a ação do Agente Seguro e a ação original orientada à utilidade, sujeito a um orçamento de informação estrito (limite de caracteres):
$$\min_{H^{(e)}_t} D(\pi_s(T, H^{(e)}_t, I^{(s)}_t), \pi(T, U, I^{(s)}_t)) \quad \text{sujeito a} \quad \text{Orçamento}(H^{(e)}_t) \leq b$$

Suposições de Segurança

A segurança do Twin Agent baseia-se em duas suposições principais:

1. Ataques Dependentes de Comprimento: Atacar modelos de fronteira via injeção de prompt normalmente requer injeções longas. Ao limitar estritamente o comprimento da dica (ex: 100–200 caracteres), o sistema impede a transmissão de informação suficiente para carregar um ataque.
2. Evasão de Detector: O sistema emprega um detector de injeção de prompt padrão no processo de análise da dica. A suposição é que encontrar uma injeção curta que simultaneamente evada a detecção e ataque com sucesso o Agente Seguro é computacionalmente inviável.

3. Principais Contribuições

1. Design do Twin Agent: Uma arquitetura de separação de privilégios que preserva a utilidade enquanto controla o fluxo de informação. Ele atua como um substituto "drop-in" para padrões ReAct padrão, exigindo mínima engenharia de fluxo de trabalho específica da tarefa.
2. Formulação de Fluxo de Informação Comprimida: O artigo reformula o design de agentes seguros como um problema de compressão de fluxo de informação. Ele postula que o equilíbrio segurança–utilidade pode ser controlado limitando a quantidade de informação permitida para cruzar a fronteira de confiança, especificamente transmitindo apenas o contexto "residual" necessário para o próximo passo.
3. Validação Empírica: Avaliação abrangente em diversos benchmarks demonstrando que o Twin Agent supera tanto agentes sem defesa quanto baselines de separação de privilégios existentes.

4. Resultados Experimentais

Os autores avaliaram o Twin Agent em três benchmarks: SWE-bench Lite (engenharia de software de longo horizonte), AgentDojo (interação multi-ferramenta heterogênea) e DecodingTrust-Agent.

Métricas de Desempenho

• Utilidade: Porcentagem de tarefas concluídas com sucesso.
• Taxa de Sucesso de Ataque (ASR): Porcentagem de ataques onde o agente segue instruções injetadas.

Principais Descobertas

• SWE-bench-injected:
  • Agente Sem Defesa: 61,2% de utilidade, 97,0% de ASR.
  • Agente Dual (Separação Estrita): 0,0% de utilidade, 0,0% de ASR (Perda total de utilidade).
  • Twin Agent: 62,5% de utilidade, 0,0% de ASR. O Twin Agent preservou a utilidade enquanto neutralizou completamente os ataques.
• AgentDojo:
  • Agente Sem Defesa: 61,9% de utilidade, 41,5% de ASR.
  • CaMeL (Planejamento Primeiro): 30,9% de utilidade, 0,0% de ASR.
  • Twin Agent: 62,9% de utilidade, 0,1% de ASR.
• DecodingTrust-Agent:
  • O Twin Agent manteve alta utilidade (~93-95%) enquanto reduziu o ASR de ~10-26% (baseline) para ~3,3%.

Ataques Adaptativos

Em um cenário de ataque adaptativo de pior caso no SWE-bench (usando o algoritmo PAIR para otimizar as dicas):

• O Agente Seguro resistiu a ataques de turno único (0,0% de ASR).
• O Agente de Exploração foi totalmente comprometido (100% de ASR) quando forçado a encaminhar payloads otimizados.
• Em um cenário de múltiplos turnos, o ASR total foi de 4,7%. Os autores observam que essas falhas parecem estocásticas (comportamento não determinístico do modelo) e poderiam ser reduzidas com melhores mecanismos de proteção ou votação.

Análise de Trade-off

Experimentos variando o orçamento da dica (50 a 200 caracteres) confirmaram o trade-off teórico:

• Orçamento Maior: Aumenta a utilidade (mais informação residual) mas aumenta o ASR (maior superfície de ataque).
• Orçamento Menor: Aumenta a segurança mas corre o risco de degradação da utilidade.
• Custo: O Twin Agent incorre em aproximadamente o dobro do custo de um agente baseline nos orçamentos ideais, o que os autores consideram um trade-off razoável pela segurança adicional.

5. Significância e Alegações

O artigo afirma que o Twin Agent oferece uma solução fundamentada e generalizável para o problema de injeção de prompt que não sacrifica a utilidade da tarefa. Ao mudar de um bloqueio de informação "absoluto" para uma compressão de informação "residual", o design:

• Unifica segurança e utilidade: Trata o equilíbrio segurança–utilidade como um parâmetro ajustável (orçamento de dica) em vez de uma escolha binária.
• Generaliza: Aplica-se a arquiteturas de agentes heterogêneas (engenharia de software, interação multi-ferramenta) sem exigir protocolos rígidos e específicos de cada tarefa.
• Praticidade: Fornece uma defesa "drop-in" para agentes orientados à utilidade existentes, facilitando a adaptação segura de sistemas atuais.

Os autores reconhecem limitações, observando que a abordagem atualmente carece de garantias formais de segurança e foi avaliada em um conjunto limitado de domínios. No entanto, eles afirmam que os resultados empíricos demonstram um caminho robusto para a construção de agentes de LLM adaptáveis, porém seguros.