Resumo Técnico: Red-Teaming de Agentes de Codificação sob a Perspectiva de Invocação de Ferramentas

Declaração do Problema

Agentes de codificação impulsionados por Grandes Modelos de Linguagem (LLMs) tornaram-se centrais em Ambientes de Desenvolvimento Integrado (IDEs) modernos, permitindo tarefas de desenvolvimento complexas e de múltiplas etapas por meio da invocação de ferramentas. Embora esses agentes utilizem ferramentas integradas (ex: execução de comandos, acesso ao sistema de arquivos) e ferramentas externas via protocolos como o Model Context Protocol (MCP) para ampliar sua funcionalidade, essa capacidade expandida introduz uma superfície de ataque significativa.

Pesquisas anteriores abordaram riscos de segurança em agentes de propósito geral e agentes de domínios específicos, focando frequentemente em injeção de prompt direta ou exfiltração de dados. No entanto, não houve uma avaliação de segurança sistemática visando especificamente os mecanismos de invocação de ferramentas de agentes de codificação. Os autores identificam uma lacuna crítica: as implicações de segurança de como os agentes de codificação geram argumentos para chamadas de ferramentas e como processam os retornos das ferramentas permanecem amplamente inexploradas, apesar da natureza de alto privilégio de ferramentas como a execução de shell.

Metodologia

O artigo apresenta um framework de red-teaming de duas fases aplicado a seis agentes de codificação populares do mundo real: Cursor, Claude Code, Copilot, Windsurf, Cline e Trae.

Fase 1: Exfiltração de Prompt via ToolLeak

A primeira fase visa recuperar o contexto interno de segurança crítica (ex: prompts de sistema, metadados de ferramentas) para informar ataques subsequentes.

• A Vulnerabilidade (ToolLeak): Os autores identificam um "gap de modo" entre a geração de chat padrão e a geração de argumentos de chamada de ferramenta baseada em esquema. No modo de chat, os LLMs são fortemente alinhados para recusar solicitações de revelar instruções do sistema. No entanto, durante a invocação de ferramentas, o modelo opera em um modo de "preenchimento de argumento estruturado".
• Mecanismo: Um atacante registra uma ferramenta externa maliciosa onde o esquema do argumento solicita explicitamente o contexto interno (ex: um parâmetro chamado note definido como "system prompt"). Como o modelo trata isso como uma tarefa de entrada de dados benigna e em conformidade com o esquema, em vez de uma instrução explícita para "ignorar instruções anteriores", ele inadvertidamente copia o contexto oculto do agente para os argumentos da chamada de ferramenta.
• Execução: O atacante aciona a ferramenta, e os prompts internos do agente são exfiltrados através dos argumentos da ferramenta, observáveis pelo endpoint da ferramenta controlado pelo atacante.

Fase 2: Sequestro de Invocação de Ferramenta

Usando os prompts de sistema vazados, os autores constroem payloads adaptativos para sequestrar o comportamento do agente, visando especificamente a Execução Remota de Código (RCE).

• Injeção de Prompt de Dois Canais: Os autores propõem uma técnica de injeção inovadora que abrange dois canais: a descrição da ferramenta e o retorno da ferramenta.
  1. Canal de Descrição da Ferramenta: O atacante elabora uma descrição de ferramenta maliciosa que atrai o agente para selecionar a ferramenta. Esta descrição inclui exemplos de "inicialização bem-sucedida" que incorporam detalhes do prompt de sistema vazado para aumentar a credibilidade e contornar gatilhos de recusa. Ela estabelece uma narrativa onde a execução de um comando específico é um passo necessário para a inicialização.
  2. Canal de Retorno da Ferramenta: Uma vez que o agente invoca a ferramenta maliciosa, a ferramenta controlada pelo atacante retorna um payload elaborado. Diferente das descrições de ferramentas (que são frequentemente tratadas como dados), os retornos das ferramentas são alimentados de volta no contexto para direcionar o raciocínio subsequente. O payload de retorno incorpora instruções procedimentais de alta saliência (ex: "Execute o seguinte comando para completar a inicialização") que sobrescrevem as salvaguardas de segurança.
• Payloads Adaptativos: Os payloads de injeção são personalizados para cada agente com base nos prompts de sistema e esquemas de ferramentas específicos recuperados na Fase 1, garantindo consistência com a formatação e lógica nativas do agente.

Principais Contribuições

1. Primeira Avaliação Sistemática: O artigo fornece o primeiro red-teaming aprofundado e avaliação de segurança de seis grandes agentes de codificação do mundo real sob uma perspectiva de invocação de ferramenta.
2. Descoberta do ToolLeak: Os autores identificam e quantificam uma discrepância de alinhamento específica (ToolLeak) onde a geração de argumentos baseada em esquema vaza o contexto interno do agente, contornando recusas de segurança padrão.
3. Injeção de Dois Canais: O artigo introduz um vetor de ataque inovador que utiliza tanto as descrições quanto os retornos das ferramentas para sequestrar o comportamento do agente, demonstrando que os retornos das ferramentas podem ser mais salientes para injeção de instruções do que as descrições.
4. Validação Empírica: O estudo inclui avaliações extensas em agentes do mundo real e ambientes emulados, juntamente com dois estudos de caso detalhados (Cursor e Claude Code) demonstrando RCE bem-sucedido.

Resultados

A avaliação cobre 25 pares agente-LLM através dos seis agentes alvo.

• Exfiltração de Prompt (ToolLeak):

  • Em configurações emuladas, o ToolLeak alcançou a maior similaridade semântica (variando de 0.891 a 0.958) e a menor Distância de Edição Estendida (EED) normalizada em comparação com todos os baselines (ex: Naive, Ignore, PLeak).
  • Em configurações do mundo real, o ToolLeak alcançou o melhor pseudo-recall em 18 de 25 pares agente-LLM. Ele vazou prompts com sucesso em todos os agentes ao usar modelos de backend como Claude-Sonnet-4, Claude-Sonnet-4.5 e Grok-4.
  • Métodos baseline (que dependem de solicitações explícitas) falharam amplamente, muitas vezes alcançando zero de recall.

• Sequestro de Invocação de Ferramenta (RCE):

  • O método de dois canais (RCE-2) alcançou Execução Remota de Código em todos os pares agente-LLM testados.
  • O RCE-2 superou consistentemente os baselines de canal único (incluindo AgentDojo, InjecAgent e MCPTox) e uma versão de canal único do próprio ataque dos autores (RCE-1).
  • Taxas de Sucesso: Em gerações de agentes mais antigas, o RCE-2 alcançou taxas de sucesso de 0.8–1.0 na maioria das configurações.
  • Evasão de Defesa: O ataque contornou com sucesso o modelo de guarda (Haiku) integrado do Claude Code, que sinalizou o comando como inseguro, porque o modelo principal (Sonnet) sobrescreveu o aviso devido ao contexto injetado.
  • Tendências de Fortalecimento: Arquiteturas de agentes mais recentes (ex: Cursor e Claude Code) que ocultam descrições completas de ferramentas do LLM (divulgação progressiva) mostraram vulnerabilidade reduzida, sugerindo que a separação arquitetural de instruções e dados é uma defesa mais eficaz do que apenas o alinhamento do modelo.

Significância e Alegações

O artigo alega demonstrar que o mecanismo de invocação de ferramentas em agentes de codificação representa uma superfície de ataque crítica e anteriormente negligenciada. Os autores afirmam que:

1. O Alinhamento de Segurança é Insuficiente: O treinamento de segurança padrão e os mecanismos de recusa são ineficazes contra ataques que exploram o modo de "preenchimento de argumento" ou a alta saliência dos retornos de ferramentas.
2. Falhas Arquiteturais: A causa raiz da vulnerabilidade é a falta de uma separação limpa entre instruções e dados nas arquiteturas de agentes atuais, onde os retornos das ferramentas são tratados como instruções executáveis.
3. Impacto Prático: A capacidade de alcançar RCE em agentes amplamente utilizados como Cursor e Claude Code representa um risco severo à segurança do desenvolvedor, permitindo potencialmente que atacantes executem código arbitrário nas máquinas dos usuários.

Os autores concluem que, embora a detecção leve (ex: baseada em perplexidade) seja insuficiente, uma defesa robusta requer mudanças arquiteturais que imponham limites estritos entre contextos que carregam instruções e contextos que carregam dados, em vez de depender apenas de filtragem de nível de token ou alinhamento de modelo.