Resumo Técnico: Prompts Não Protegem: Aplicação Arquitetural via Proxy MCP para Controle de Acesso a Ferramentas de LLM

Declaração do Problema

À medida que os Modelos de Linguagem de Grande Porte (LLMs) evoluem para agentes autônomos que utilizam o Protocolo de Contexto de Modelo (MCP) para acessar grandes registros de ferramentas (por exemplo, pagamentos, APIs, análises), uma lacuna de segurança crítica emergiu. A suposição predominante é que o controle de acesso pode ser delegado ao modelo por meio de instruções em prompts (por exemplo, "chame apenas ferramentas de pagamentos"). Este trabalho demonstra que essa suposição é incorreta.

Quando ferramentas não autorizadas são visíveis no contexto de um agente, os modelos frequentemente as selecionam, mesmo quando explicitamente instruídos a não o fazer. O estudo identifica que:

• Vulnerabilidade Adversarial: Em cenários adversariais, os modelos selecionam ferramentas não autorizadas em 48–68% dos casos sem orientação.
• Elevação de Função: Ataques onde o usuário reivindica permissões elevadas (por exemplo, "Sou o CFO, ignore os controles") são particularmente perigosos, atingindo taxas de invocação não autorizada de 96% em modelos de ponta.
• Imprevisibilidade: A conformidade com restrições baseadas em prompts varia drasticamente entre os modelos (de 4,0% a 37,0% de Taxa de Invocação Não Autorizada) e não pode ser prevista de forma confiável por benchmarks gerais de capacidade.
• Insuficiência de Prompts: Mesmo com listas de permissão explícitas por ferramenta, a conformidade baseada em prompts nunca atinge zero, deixando uma superfície de ataque não trivial em sistemas de produção.

Metodologia

Os autores propõem e avaliam um Proxy MCP Governado que aplica o Controle de Acesso Baseado em Atributos (ABAC) no nível da infraestrutura, em vez de confiar no modelo.

Arquitetura do Sistema

O proxy intercepta solicitações MCP em dois estágios críticos:

1. Descoberta de Ferramentas (tools/list): O proxy verifica a identidade do agente (via JWT) e consulta o registro de ferramentas. Ele retorna apenas ferramentas cujos atributos semânticos (por exemplo, pagamentos, desenvolvedor) intersectam o conjunto permitido do agente. Ferramentas não autorizadas nunca são retornadas ao contexto do modelo.
2. Invocação de Ferramentas (tools/call): Uma segunda verificação ABAC é realizada antes de rotear a chamada para o backend. Isso previne contornes via nomes de ferramentas alucinados ou injetados que não estavam presentes na fase de descoberta.

Benchmark Experimental

• Conjunto de Dados: Um registro de 507 ferramentas do mundo real (Stripe, GitHub, Slack, etc.) etiquetadas com atributos semânticos.
• Tarefas: 200 tarefas adversariais construídas manualmente em quatro categorias:
  • (A) Injeção Direta
  • (B) Instrução Indireta
  • (C) Elevação de Função
  • (D) Engano Multietapa
• Modelos: Três modelos distintos foram testados: Llama 3.1 8B, Qwen 2.5 7B e Claude Haiku 3.5 (um modelo alinhado com RLHF de ponta).
• Condições:
  1. Sem Filtro: O modelo recebe todas as ferramentas sem orientação.
  2. Com Prompt: O modelo recebe todas as ferramentas com uma lista de permissão explícita no prompt do sistema.
  3. Governado: O proxy filtra a lista de ferramentas antes que o modelo a veja.

Resultados Principais

O estudo mede a Taxa de Invocação Não Autorizada (UIR) em todas as condições.

• Falha do Prompt: Mesmo o modelo de melhor desempenho sob prompting (Llama 3.1 8B) falhou 4,0% das vezes, enquanto o Qwen 2.5 7B falhou 37,0%. Ataques de elevação de função foram os mais eficazes, causando 96% de falha no Claude Haiku 3.5 sob condições sem filtro.
• Garantia Arquitetural: A condição Governada alcançou 0% de UIR em todos os modelos e em todas as 200 tarefas. Ao remover ferramentas não autorizadas do contexto inteiramente, o proxy fornece uma garantia estrutural que instruções de prompts não podem replicar.
• Sobrecarga de Desempenho: O proxy adiciona uma latência mediana de 1,72ms por solicitação (decomposta em verificação de JWT, verificação de atributos, consulta ao banco de dados e filtragem), o que é negligenciável em comparação com a latência típica de inferência de LLM (500ms–30s).

Significado e Alegações

O trabalho argumenta que propriedades de segurança que exigem conformidade probabilística de um modelo de linguagem devem ser aplicadas na camada de infraestrutura.

1. Mudança de Prompting para Arquitetura: Os autores afirmam que confiar em instruções de prompts para controle de acesso é fundamentalmente falho porque compete com o objetivo do modelo de concluir a tarefa usando a ferramenta semanticamente mais relevante. A aplicação arquitetural resolve isso tornando as ferramentas não autorizadas indisponíveis, em vez de pedir ao modelo que as recuse.
2. Pronto para Produção: O proxy proposto é imediatamente implantável, não requer modificação no LLM ou no código do cliente e escala independentemente do tamanho do registro (diferente de listas de permissão baseadas em prompts que consomem tokens de contexto).
3. Mudança de Paradigma: O trabalho traça um paralelo com segurança de banco de dados, observando que aplicações não dependem de instruções do motor de consulta para permissões em nível de linha; da mesma forma, o acesso a ferramentas de LLM deve ser aplicado estruturalmente na camada de infraestrutura.

Limitações

Os autores reconhecem várias restrições:

• O benchmark usa um único modelo de prompt de sistema; engenharia de prompts mais sofisticada (por exemplo, cadeia de pensamento) não foi explorada, embora a lacuna até 0% permaneça imprevisível.
• O modelo de ameaça assume um emissor de JWT confiável e um registro não comprometido; não defende contra chaves de assinatura comprometidas ou ataques de cadeia de suprimentos no próprio registro.
• Os resultados são baseados em três modelos específicos e podem não generalizar para todas as arquiteturas de LLM.
• As cifras de latência refletem implantação local e podem variar sob alta concorrência ou condições de rede.