Resumo Técnico: Pense Duas Vezes Antes de Agir

Declaração do Problema

A integração de ferramentas externas expandiu significativamente as capacidades dos agentes de Grandes Modelos de Linguagem (LLMs), mas introduziu novas superfícies de ataque além da injeção de prompt tradicional. Este artigo identifica e formaliza o envenenamento de descrição entre ferramentas (cross-tool description poisoning), um vetor de ataque sofisticado onde adversários manipulam os metadados (descrições) de ferramentas não críticas ou fracamente regulamentadas para desviar a trajetória de planejamento de um agente.

Ao contrário de ataques anteriores de "preferência de ferramenta" que enviesam um agente para selecionar uma ferramenta específica envenenada, o envenenamento de descrição entre ferramentas permite que um adversário induza ações maliciosas envolvendo outras ferramentas — mesmo que a própria ferramenta envenenada nunca seja selecionada. Por exemplo, envenenar a descrição de uma ferramenta benigna de "Backup de Conta" pode fazer com que o planejador insira uma etapa maliciosa de "Envio de E-mail" (ex: enviando detalhes da conta para um atacante) na trajetória de uma tarefa legítima de "Transferência Bancária". O desafio central é que as descrições envenenadas persistem no contexto de planejamento através de múltiplas etapas, permitindo influência contínua sobre escolhas de ferramentas subsequentes.

Defesas existentes, como filtragem estática de ferramentas, repetição de prompts ou restrições ao nível do sistema (ex: Drift, Progent), mostraram-se ineficazes contra este tipo específico de ameaça. Esses métodos ou falham em considerar o contexto da tarefa, dependem de estados internos do modelo (que são frequentemente inacessíveis via APIs) ou não conseguem distinguir entre o uso benigno de uma ferramenta e o uso influenciado por metadados envenenados.

Metodologia: Tool-Guard

Para abordar essas limitações, os autores propõem o Tool-Guard, um novo sistema de defesa baseado no conceito de planejamento isolado. A filosofia central é aplicar o princípio de segurança do isolamento ao planejamento de agentes, quebrando a conexão entre as descrições envenenadas e o alvo pretendido da influência sem desativar permanentemente as ferramentas.

Mecanismo Central

O Tool-Guard opera através de um loop dinâmico e iterativo envolvendo três etapas principais:

1. Particionamento Dinâmico do Conjunto de Ferramentas:
   O sistema mantém um particionamento dinâmico do conjunto de ferramentas disponíveis $K$ em duas listas disjuntas:

   • Lista de Influenciados ($K_{inf}$): Contém ferramentas suspeitas de serem influenciadas por descrições envenenadas (inicialmente vazia).
   • Lista de Outros ($K_{others}$): Contém as demais ferramentas.
     As ferramentas não são assumidas como maliciosas; em vez disso, elas são movidas para $K_{inf}$ se sua invocação parecer desalinhada com a intenção do usuário ou mal fundamentada no contexto.

2. Planejamento Isolado:
   Em vez de consultar o planejador com o conjunto completo de ferramentas, o Tool-Guard consulta o planejador duas vezes sob isolamento estrito:

   • Uma vez apenas com as descrições em $K_{inf}$.
   • Uma vez apenas com as descrições em $K_{others}$.
     Isso evita que uma descrição envenenada em um subconjunto direcione a seleção ou parametrização de ferramentas no outro subconjunto. O sistema então seleciona uma ação candidata a partir dos dois planos resultantes. Se ambos os subconjuntos gerarem ações válidas, um critério de desempate é aplicado; se nenhum deles o fizer, a trajetória é encerrada.

3. Validação Pré-Execução e Atualização da Lista:
   Antes de executar uma chamada de ferramenta selecionada, o Tool-Guard realiza duas verificações semânticas usando um validador baseado em LLM:

   • Verificação de Alinhamento: Verifica se a ação é consistente com a intenção do usuário e com o progresso validado.
   • Verificação de Suspeita: Verifica se os argumentos estão fundamentados na requisição do usuário ou em saídas de ferramentas anteriores, sinalizando entidades sensíveis (ex: endereços de destinatários) que carecem de procedência clara.

   Se a validação falhar, a ferramenta é movida para a Lista de Influenciados, e o planejador é acionado para replanejar sob o particionamento atualizado. Este processo iterativo isola progressivamente caminhos de influência prejudiciais enquanto preserva a utilidade das ferramentas legítimas.

Extensão para MCP

A metodologia estende-se ao Protocolo de Contexto de Modelo (MCP) aplicando a mesma lógica de isolamento ao nível do servidor, particionando servidores em grupos influenciados e não influenciados para evitar o envenenamento entre servidores.

Principais Contribuições

1. Caracterização do Envenenamento de Descrição Entre Ferramentas: O artigo demonstra que adversários podem injetar etapas maliciosas em invocações de ferramentas críticas de segurança ao envenenar descrições de ferramentas não críticas, mesmo quando a ferramenta envenenada nunca é chamada. Mostra que as defesas existentes apresentam altas Taxas de Sucesso de Ataque (ASR) contra esta influência contínua.
2. Defesa Tool-Guard: Os autores propõem uma defesa que particiona dinamicamente o conjunto de ferramentas e emprega planejamento isolado. Ao validar ações antes da execução e isolar ferramentas suspeitas, ela corta caminhos de direcionamento malicioso entre ferramentas enquanto mantém a disponibilidade total das ferramentas.
3. Avaliação Abrangente: Experimentos extensos nos benchmarks AgentDojo e ASB (Agent Security Bench) demonstram que o Tool- Guard reduz a ASR para níveis insignificantes, preservando simultaneamente alta utilidade de tarefa. O artigo também quantifica a eficiência e a robustez contra variantes de ataques adaptativos.

Resultados Experimentais

Os autores avaliaram o Tool-Guard contra cinco mecanismos de defesa existentes (System Prompt, Tool Filtering, Repeat Prompt, Drift, Progent) através de múltiplos LLMs (GPT-4o, GPT-4o-mini, Gemini-2.5, Claude-3.5) em dois benchmarks.

• Taxa de Sucesso de Ataque (ASR): O Tool-Guard reduziu a ASR para níveis insignificantes (ex: de ~43% para ~2% ou 0% no AgentDojo, e de ~72-96% para 0% no ASB para a maioria dos modelos). Em contraste, as defesas existentes frequentemente falharam em reduzir a ASR significativamente (ex: Drift e Progent mostraram ASRs de 24,7% e 19,6%, respectivamente, no AgentDojo).
• Preservação de Utilidade: O Tool-Guard manteve alta utilidade de tarefa tanto em condições benignas quanto de ataque. Diferente de defesas de "excesso de zelo" (over-kill) que bloqueiam ferramentas indiscriminadamente, o Tool-Guard preservou a capacidade de completar tarefas, com pontuações de utilidade comparáveis ou superiores às das linhas de base sob ataque.
• Eficiência:
  • Sobrecarga de Tokens: O Tool-Guard incorreu em um aumento de aproximadamente 1,5× no uso de tokens em comparação com a linha de base sem defesa, significativamente menor do que outras defesas de nível de sistema como Drift ou Progent.
  • Latência: O método introduziu um overhead de tempo de execução de aproximadamente 3,7× em relação à linha de base (maior que os 1,2× do Progent, mas menor que os 7,3× do Drift), atribuído ao mecanismo de replanejamento.
• Robustez:
  • Estabilidade: A defesa permaneceu estável em múltiplas execuções com baixos desvios padrão.
  • Ataques Adaptativos: O Tool-Guard permaneceu robusto contra ataques semanticamente adaptativos (que tentam evitar verificações via justificativas fabricadas) e ataques baseados em otimização (PAIR, TAP). Embora os ataques baseados em otimização tenham aumentado ligeiramente a ASR, ela permaneceu muito baixa (ex: 2,06% sob PAIR), destacando o compromisso inerente que os atacantes enfrentam entre ser explícito o suficiente para influenciar o planejamento e sutil o suficiente para evitar a validação.
  • Testes de Estresse: Mesmo quando ferramentas críticas de alta frequência foram envenenadas, o Tool-Guard manteve a ASR em um nível baixo de um dígito.

Significância e Alegações

O artigo afirma que as descrições de ferramentas representam uma superfície de ataque crítica e anteriormente inexplorada em agentes de LLM. A significância deste trabalho reside em:

1. Identificar um Novo Vetor de Ameaça: Formalizar o envenenamento de descrição entre ferramentas, que contorna as defesas tradicionais ao explorar a natureza persistente dos metadados das ferramentas no contexto de planejamento.
2. Demonstrar as Limitações das Defesas: Mostrar que as defesas atuais de última geração são insuficientes contra a influência contínua entre ferramentas.
3. Propor uma Solução de Nível de Sistema: Introduzir o Tool-Guard, que mitiga efetivamente esses ataques ao isolar a influência em vez de depender apenas de salvaguardas no momento da execução ou varredura estática.
4. Equilibrar Segurança e Utilidade: Provar que uma defesa eficaz não requer sacrificar a utilidade do agente; o Tool-Guard alcança segurança robusta com overhead mínimo de tokens e sem comportamento de "excesso de zelo".

Os autores concluem que as defesas eficazes para agentes de LLM aumentados por ferramentas devem abordar explicitamente a influência entre ferramentas através de mecanismos como o planejamento isolado, em vez de depender apenas de defesas contra injeção de prompt ou filtragem estática de ferramentas.