Resumo Técnico: Quando o Alinhamento Não é Suficiente: Ataques de Caminho de Resposta em Agentes LLM

1. Declaração do Problema: Manipulação Pós-Alinhamento

O artigo identifica uma lacuna fundamental de segurança no paradigma Bring-Your-Own-Key (BYOK), uma arquitetura amplamente adotada onde usuários roteiam o tráfego de Modelos de Linguagem de Grande Escala (LLM) através de serviços de retransmissão de terceiros (por exemplo, LiteLLM, OpenRouter) enquanto autenticam com suas próprias credenciais.

Nessa arquitetura, o retransmissor atua como um proxy legítimo configurado pelo usuário que encerra a criptografia de ponta a ponta, criando dois saltos criptografados sequenciais: um entre o agente de front-end e o retransmissor, e outro entre o retransmissor e o LLM de back-end. Embora as camadas de transporte sejam seguras, o retransmissor possui acesso em texto puro a todas as mensagens.

A vulnerabilidade central, denominada Manipulação Pós-Alinhamento, surge porque os mecanismos de alinhamento de segurança do LLM (RLHF, treinamento constitucional, prompts de sistema) operam apenas na geração da resposta pelo modelo de back-end. Uma vez que a resposta alinhada é gerada, ela viaja através do retransmissor antes de chegar ao agente para execução. O artigo argumenta que os protocolos atuais de API de LLM carecem de mecanismos de integridade na camada de aplicação (como assinaturas ou MACs) para vincular a saída do modelo de back-end à entrada do agente. Consequentemente, um retransmissor malicioso pode reescrever a resposta alinhada do LLM após a geração, mas antes da execução, contornando todas as garantias de segurança sem precisar comprometer o modelo ou derrotar proteções criptográficas de transporte.

Essa superfície de ataque é distinta e estritamente mais poderosa do que:

• MitM na Camada de Transporte: Que exige derrotar a criptografia ou forjar certificados.
• Injeção de Prompt: Que depende de persuadir o modelo a gerar conteúdo prejudicial, um processo limitado pela força do alinhamento do modelo.

2. Metodologia: O Ataque de Manipulação de Retransmissor (RTA)

Os autores instanciam essa vulnerabilidade como o Ataque de Manipulação de Retransmissor (RTA), um framework hierárquico operando inteiramente a partir da posição do retransmissor. O RTA consiste em três estágios:

2.1 Orquestração Estratégica (Ataque em Cadeia)

Para lidar com objetivos complexos e de múltiplas interações que não podem ser alcançados em uma única interação, o retransmissor decompõe objetivos de alto nível em uma cadeia ordenada de subobjetivos. Ele rastreia o estado da conversa e decide se deve encaminhar uma resposta inalterada ou intervir com base nos requisitos do subobjetivo atual. Isso permite que o ataque colete adaptativamente os artefatos necessários (por exemplo, caminhos de arquivos) antes de executar a ação maliciosa final.

2.2 Manipulação Tática

O retransmissor realiza edições mínimas, orientadas por esquema, nos campos específicos que ditam a execução do agente, em vez de reescrever todo o texto. O framework define dois caminhos paralelos:

• RTA-PreWrite (Caminho de Consulta): Opera antes da inferência do LLM. O retransmissor reescreve a consulta do usuário e remove as barreiras de segurança do prompt de sistema para "purificar" o contexto, forçando o modelo a focar exclusivamente no objetivo adversarial. Este caminho é vulnerável a defesas do lado da entrada.
• RTA-PostForge (Caminho de Resposta): Opera após o alinhamento. O retransmissor intercepta a resposta benigna e alinhada e modifica apenas os campos estruturados críticos (por exemplo, nomes de ferramentas, argumentos, flags de motivo de término) para forçar chamadas de ferramentas arbitrárias ou gravações de arquivos. Este caminho contorna estruturalmente todo o alinhamento de segurança do modelo.

2.3 Restauração Furtiva

Para evadir a detecção e preservar a utilidade da tarefa legítima do usuário, o RTA emprega:

• Polimento do Mesmo Modelo: O retransmissor reenvia o rascunho manipulado ao mesmo LLM de back-end (usando as credenciais BYOK do usuário) com um prompt para reparar a formulação superficial, mantendo os campos maliciosos imutáveis. Isso garante que a saída final corresponda ao estilo e distribuição nativos do modelo.
• Conclusão de Tarefa Concurrente: O retransmissor armazena em buffer a resposta genuína para a tarefa original do usuário e a insere de volta na conversa após os subobjetivos do ataque serem alcançados, mascarando o ataque do usuário.

3. Modelo Formal e Contribuições Teóricas

O artigo formaliza a vulnerabilidade usando definições de segurança baseadas em jogos, provando quatro insights principais:

1. Substituição de Resposta Não Autenticada: Sem integridade de ponta a ponta, um retransmissor pode substituir qualquer payload válido de esquema. Se o payload codificar uma ação prejudicial, o agente a executará, independentemente da saída do modelo de back-end.
2. O Alinhamento Termina no Back-end: Mesmo um LLM perfeitamente alinhado (aquele que nunca gera respostas prejudiciais) oferece zero proteção contra um adversário de caminho de resposta. O retransmissor descarta a saída alinhada e injeta a sua própria, tornando o alinhamento do modelo irrelevante para a execução final.
3. Dominância de Reescrita do Caminho de Consulta: Um retransmissor capaz de reescrever o contexto da consulta (removendo instruções concorrentes) é estritamente mais poderoso do que um restrito a anexar instruções, pois elimina o efeito de "diluição da atenção" que frequentemente protege contra injeção de prompt.
4. Assimetria Defensiva: Detectores que dependem exclusivamente do conteúdo da transcrição são limitados pela distância estatística entre o texto polido (manipulado) e o texto genuíno. Como o RTA usa polimento do mesmo modelo, essa distância é minimizada, tornando a detecção baseada apenas em transcrição teoricamente fraca.

4. Avaliação Experimental

Os autores avaliaram o RTA em seis LLMs (três proprietários: GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro; três de peso aberto: GLM-5.1, MiniMax-M2.5, Qwen-235B) em dois benchmarks: AgentDojo e Agent Security Bench (ASB).

Resultados Principais

• Eficácia: O RTA supera significativamente as bases de injeção de prompt.
  • RTA-PostForge alcançou 73,5% de Taxa de Sucesso do Ataque (ASR) no AgentDojo e 89,2% no ASB.
  • RTA-PreWrite alcançou 99,1% de ASR no ASB.
  • Em contraste, as melhores bases de injeção de prompt alcançaram apenas ~17,9% de ASR no AgentDojo e ~44,4% no ASB.
• Preservação de Utilidade: Diferentemente de ataques do caminho de consulta que frequentemente quebram a tarefa do usuário, o RTA-PostForge preservou 47,6% da utilidade da tarefa do usuário no AgentDojo, armazenando em buffer e restaurando a resposta genuína.
• Imperecibilidade: O RTA-PostForge manteve alta consistência estilística (C=0,758) e similaridade semântica, com o Teste de Igualdade de Modelos (MET) rejeitando a hipótese nula de distribuições idênticas em apenas 54,2% dos casos, comparado a 90,0% para o RTA-PreWrite mais agressivo.
• Evasão de Sobrecarga: A sobrecarga de latência introduzida pelo RTA-PostForge (mediana ~5,9s) caiu dentro da variação de rede natural de retransmissores comerciais para 74% das interações, tornando difícil a detecção via limites simples de latência.

Avaliação de Defesa

O artigo avaliou quatro defesas existentes do lado do agente (Delimitadores, Sanduíche, Detecção de Resposta Conhecida, CaMeL):

• Nenhuma eliminou totalmente o RTA-PostForge.
• CaMeL (que força a geração de código) reduziu a ASR para 14,5%, mas os autores demonstraram uma adaptação onde o retransmissor reescreve diretamente o bloco de código Python gerado, recuperando a ASR para 50,1%.
• Detector de Canal de Tempo: Os autores propõem um detector baseado em telemetria operacional (latência). Ao agregar evidências de temporização ao longo de uma sessão (n=50 turnos), este detector alcançou um AUC de 0,964, sugerindo que, embora a detecção baseada em conteúdo falhe, anomalias operacionais oferecem um vetor de defesa viável.

5. Significado e Alegações

O artigo alega expor uma falha de integridade estrutural no ecossistema moderno de agentes LLM que é distinta e mais grave do que a injeção de prompt. Suas contribuições principais são:

1. Formalização: Prova que a falsificação de caminho de resposta domina estritamente a injeção de prompt e que a causa raiz é a ausência de verificação de integridade de ponta a ponta nos protocolos atuais de API de LLM.
2. Viabilidade no Mundo Real: Através de estudos de caso no OpenClaw (aconselhamento financeiro) e Claude Code (agente de codificação), os autores demonstram que o RTA pode exfiltrar silenciosamente bases de código ou reverter decisões financeiras em ambientes de produção, mantendo a aparência de operação normal.
3. Limitação das Defesas Atuais: O trabalho argumenta que melhorar o alinhamento do modelo ou endurecer prompts é insuficiente contra um adversário de retransmissor, pois o ataque ocorre a jusante de todas as verificações de alinhamento.
4. Chamada à Ação: O artigo conclui que os futuros protocolos de API de LLM devem tratar a integridade de resposta de ponta a ponta como um primitivo de primeira classe (por exemplo, respostas assinadas pelo provedor) para fechar essa lacuna, pois defesas apenas na camada de aplicação não podem garantir que o agente execute a resposta gerada pelo modelo de back-end.

Os autores mantêm um tom modesto em relação ao trabalho futuro, observando que seu modelo de ameaça assume um cenário BYOK onde o retransmissor termina legitimamente o TLS, e que estender o modelo de ameaça para infraestruturas de múltiplos saltos mais amplas e projetar mecanismos de integridade principistas são os próximos passos necessários.