Resumo Técnico: Agentes de Chamada de Função de Blue Teaming

Declaração do Problema

Agentes de chamada de função estendem os Grandes Modelos de Linguagem (LLMs) ao permitir a interação com ambientes externos e a execução de ferramentas. Embora protocolos como Agent2Agent (A2A) e o Model Context Protocol (MCP) estejam impulsionando a adoção de aplicações agênticas, a robustez de segurança desses sistemas permanece não comprovada. A literatura existente indica que as capacidades de chamada de função não garantem inerentemente resistência a ataques adversários, mesmo quando defesas são impostas. Este artigo aborda a falta de avaliação de segurança empírica direcionada especificamente a modelos de chamada de função de código aberto, observando que trabalhos anteriores focaram amplamente em sistemas proprietários ou careceram de uma análise detalhada da implementação de ferramentas.

Metodologia

Os autores conduziram uma avaliação experimental utilizando quatro LLMs de código aberto que alegam possuir capacidades de chamada de função:

• Qwen3:8B
• Llama-3.2:3B
• Granite3.2:8B
• Granite3.3:8B

Estes modelos foram selecionados por sua natureza de código aberto, popularidade e alinhamento com objetivos de desenvolvimento de IA sustentável (menor consumo de energia). A avaliação utilizou o conjunto de dados Berkeley Function Calling Leaderboard (BFCL), especificamente um subconjunto sanitizado de 172 pares de consulta-resposta envolvendo chamadas de função única. Para simular condições realistas onde agentes têm acesso ao código da ferramenta, os autores geraram implementações de ferramentas plausíveis usando Qwen2.5-Coder:32B.

O estudo avaliou três vetores de ataque distintos e oito mecanismos de defesa (tanto preventivos quanto ativos):

Vetores de Ataque

Todos os ataques visavam induzir o agente a chamar uma função alvo maliciosa específica (get_result) com o parâmetro param1=true, que executa uma injeção de SQL (DROP TABLE users).

1. Injeção de Prompt Direta (DPI): Incorpora instruções maliciosas diretamente nas consultas do usuário para sobrescrever os prompts do sistema e forçar a chamada da ferramenta maliciosa.
2. Envenenamento de Ferramenta Simples (STP): Modifica as descrições das ferramentas para incluir instruções maliciosas, induzindo o agente a selecionar a ferramenta maliciosa em vez das legítimas.
3. Envenenamento de Renomeação de Ferramenta (RTP): Um ataque inovador que explora a visibilidade da implementação da ferramenta. Ele manipula simultaneamente as descrições e as implementações das ferramentas. Injeta um payload na descrição direcionando o agente para inspecionar variáveis de implementação, e um payload correspondente malicioso é atribuído a uma variável dentro do código da ferramenta.

Mecanismos de Defesa

• Defesas Preventivas:
  • Similaridade de Cosseno: Utiliza um modelo de embedding para corresponder as consultas do usuário às ferramentas, delegando a seleção ao modelo de embedding.
  • Ofuscação de Ferramenta: Renomeia sistematicamente funções e variáveis nas implementações das ferramentas para interromper ataques baseados em renomeação.
  • Reescrita de Descrição: Utiliza um LLM especializado em análise de código (Granite-Code:8B) para regenerar as descrições das ferramentas baseando-se estritamente em suas implementações reais, removendo discrepâncias.
• Defesas Ativas:
  • Marca d'água (Watermarking): Implementa autenticação criptográfica (HMAC/SHA-256) para nomes de ferramentas para detectar modificações não autorizadas.
  • Detectores Baseados em LLM: Utiliza um modelo guardião (granite-guardian-3.2-3b-a800m) para detectar:
    • Jailbreak de Consulta: Identifica tentativas de DPI.
    • Consistência de Consulta-Resposta: Valida se as respostas do modelo alinham-se com os inputs esperados.
    • Jailbreak de Ferramentas: Escaneia as implementações e descrições das ferramentas em busca de comprometimento.
    • Consistência de Consulta-Ferramentas: Analisa a relevância das ferramentas selecionadas em relação às consultas do usuário.

Principais Resultados

A avaliação revelou que os modelos de chamada de função não são seguros por padrão.

• Vulnerabilidade: Sem defesas, as Taxas de Sucesso de Ataque (ASR) variaram significativamente por modelo e tipo de ataque.
  • DPI foi altamente eficaz contra Qwen3:8B (94% de ASR) e Llama3.2:3B (58% de ASR), mas ineficaz contra Granite3.3:8B (0% de ASR).
  • STP alcançou um ASR de 95% contra Qwen3:8B, mas teve taxas de sucesso menores em outros modelos.
  • RTP foi eficaz apenas contra Qwen3:8B (74% de ASR), sugerindo que este modelo atribui um peso desproporcional aos detalhes de implementação da ferramenta em comparação com as descrições.
• Eficácia da Defesa:
  • Reescrita de Descrição provou ser altamente eficaz contra ataques de envenenamento de ferramenta (STP e RTP), reduzindo o ASR para zero nesses cenários com impacto negligenciável na precisão.
  • Marca d'água detectou com sucesso 100% das chamadas de ferramentas maliciosas (pois o atacante não possui a chave secreta), mas falhou para o Llama3.2:3B devido à sua incapacidade de reportar a marca d'água exatamente.
  • Defesas Ativas Baseadas em LLM geralmente sofreram de altas Taxas de Falso Positivo (FPR). Por exemplo, os detectores de "Consistência de Consulta-Resposta" e "Consistência de Consulta-Ferramentas" sinalizaram 11–13% das interações seguras como maliciosas. O detector de "Jailbreak de Ferramentas" apresentou um FPR muito alto para cenários de não-ataque e DPI.
  • Similaridade de Cosseno mostrou resultados mistos, melhorando a precisão em alguns casos, mas degradando-a significativamente em outros.

Significância e Contribuições

O artigo apresenta as seguintes contribuições para o campo da segurança de sistemas agênticos:

1. Foco Empírico em Código Aberto: Diferente de trabalhos anteriores focados em modelos proprietários, este estudo fornece uma avaliação focada em sistemas de chamada de função de código aberto, destacando suas vulnerabilidades específicas.
2. Identificação de Novos Vetores de Ataque: Os autores identificam que a visibilidade da implementação da ferramenta cria oportunidades de ataque únicas não abordadas anteriormente. Isso levou à introdução do Envenenamento de Renomeação de Ferramenta (RTP) e da defesa correspondente, Ofuscação de Ferramenta.
3. Limitações das Defesas Atuais: O estudo demonstra que, embora defesas específicas (como Reescrita de Descrição e Marca d'água) mostrem promessa, nenhuma defesa única fornece proteção abrangente contra todos os tipos de ataque.
4. Restrições Práticas: Os autores concluem que os atuais modelos "guardiões" baseados em LLM ainda não são viáveis para implantação no mundo real devido às altas Taxas de Falso Positivo ou falta de generalização. Eles sugerem que o progresso futuro requer modelos especializados treinados em conjuntos de dados específicos de chamada de função, que atualmente não existem.

Em resumo, o artigo afirma que, embora os sistemas agênticos estejam se tornando populares, eles carecem de robustez inerente. Os mecanismos de defesa atuais são ou muito específicos para certos ataques ou introduzem fricção operacional inaceitável (alto FPR), indicando a necessidade de soluções de segurança mais especializadas e específicas para cada cenário.