Resumo Técnico: MCP-SandboxScan (SandScope)

Declaração do Problema

O Model Context Protocol (MCP) permite que agentes de Large Language Models (LLMs) invoquem ferramentas externas e acessem fontes de dados, criando uma nova superfície de cadeia de suprimentos de software. Embora as ferramentas sejam instaladas como pacotes de terceiros, seus resultados frequentemente entram no contexto de raciocínio do agente. Esta arquitetura introduz um risco de funcionário confundido (confused-deputy risk): entradas controladas por atacantes (ex: argumentos gerados por LLM, páginas web recuperadas ou metadados de repositórios) podem induzir ferramentas, de outra forma benignas ou confiáveis, a exercer autoridade legítima sobre arquivos locais, variáveis de ambiente ou operações de rede. O perigo crítico é que essas ferramentas podem retornar conteúdo sensível ou de instrução para campos visíveis ao LLM, efetivamente vazando segredos ou injetando instruções na próxima etapa de raciocínio do agente.

As abordagens de segurança existentes são insuficientes porque:

1. A inspeção estática de descrições de ferramentas ou código-fonte não consegue detectar comportamentos que se manifestam apenas em tempo de execução (ex: acesso a arquivos ofuscado ou segredos derivados de leituras de arquivos em tempo de execução).
2. O monitoramento baseado em proxy de tráfego frequentemente falha em capturar comportamentos internos de processos de ferramentas ou o fluxo específico de dados de entradas externas para saídas visíveis ao LLM.
3. A execução direta de ferramentas de terceiros no host é insegura devido aos amplos privilégios que essas ferramentas frequentemente herdam.

Existe uma lacuna em observabilidade e contenção em tempo de execução: auditores precisam observar fluxos de entradas externas para saídas visíveis ao LLM sem conceder às ferramentas não confiáveis autoridade irrestrita sobre o host.

Metodologia: Estrutura SandScope

Os autores propõem o SandScope, uma estrutura de auditoria ciente de MCP que combina execução controlada com detecção de testemunha em tempo de execução e perfilamento semântico de ferramentas. Ele opera sem assumir que o próprio código da ferramenta seja malicioso, focando no comportamento de funcionário confundido induzido por entradas externas.

1. Backends de Execução

O SandScope suporta dois caminhos de execução para equilibrar contenção e fidelidade de protocolo:

• Caminho Sandbox WASI: Para ferramentas portáteis (artefatos WebAssembly ou aqueles envolvidos em adaptadores leves), o SandScope as executa sob a WebAssembly System Interface (WASI). Isso concede capacidades explícitas e limitadas (ex: diretórios de dados pré-abertos específicos, variáveis de ambiente específicas) e nega acesso à rede por padrão.
• Caminho Nativo stdio: Para servidores MCP não modificados (Node.js, Python, Go, etc.), o SandScope os conduz via entrada/saída padrão. Embora isso preserve a fidelidade do protocolo, depende de sandboxing externo ao nível do SO (ex: Docker, Bubblewrap) para contenção.

2. Pipeline de Evidência

A estrutura segue um pipeline de seis estágios:

1. Configuração da Fonte de Auditoria: O SandScope semeia valores "canário" distinguíveis em variáveis de ambiente, diretórios de arquivos e argumentos de chamada de ferramenta. Ele também rastreia sinais de intenção de rede (ex: strings que sugerem requisições de saída).
2. Descoberta e Adaptação de Alvo: Identifica o alvo (artefato portátil vs. servidor nativo) e seleciona o caminho de execução apropriado. Para servidores nativos, realiza uma varredura rasa para recuperar metadados de tools/list.
3. Execução Controlada: O alvo é executado. Para servidores nativos, um driver inicializa o protocolo, solicita listas de ferramentas e invoca ferramentas.
4. Monitoramento em Tempo de Execução: O sistema registra stdout/stderr delimitados, códigos de saída, transcrições MCP (JSON-RPC) e eventos de sandbox (ex: conexões negadas).
5. Extração de Sink (Sumidouro): O SandScope identifica sinks visíveis ao LLM — regiões textuais provavelmente a serem reinseridas no prompt do agente. Estes incluem:
   • Linhas contendo marcadores de prompt (ex: PROMPT:).
   • Campos prompt ou messages em respostas JSON.
   • Nós folha com valores de string em retornos estruturados de ferramentas.
6. Detecção de Testemunha: O sistema combina canários de origem com sinks extraídos. Ele emprega um detector de evidência positiva que verifica:
   • Substrings exatas.
   • Janelas de prefixo/sufixo (para capturar vazamentos parciais como chaves de API).
   • Formas normalizadas e decodificadas (lidando com ROT13, Hex, Base64 e fragmentação de separadores).

3. Perfilamento Semântico

Para abordar casos onde a execução dinâmica falha (devido a erros de build, falta de credenciais ou estado complexo), o SandScope inclui uma camada semântica. Ele extrai capacidades declaradas de:

• Respostas de tempo de execução de tools/list.
• Registros estáticos de nível de código-fonte (ex: decoradores, definições de função).
• Metadados de repositório (READMEs).
  Esta camada caracteriza a superfície de ataque (ex: "acesso à rede", "acesso ao sistema de arquivos") e prioriza ferramentas para teste, mesmo que não possam ser executadas dinamicamente.

Principais Contribuições

1. Definição de Sinks de Segurança de MCP: Os autores definem formalmente os campos de resposta do MCP visíveis ao LLM (resultados de ferramentas, campos de prompt/mensagem, payloads estruturados) como sinks de segurança de nível de protocolo e enquadram a exposição externa-para-sink como um risco em tempo de execução.
2. Pipeline de Auditoria em Tempo de Execução Baseado em Cenários: Um sistema que executa ferramentas sob WASI ou conduz servidores stdio nativos, ligando fontes de ambiente, arquivo e entrada de ferramenta a testemunhas auditáveis de origem-para-sink via caixa-preta, enquanto registra separadamente evidências de intenção de rede.
3. Perfilamento Semântico Complementar: Um método para recuperar metadados de ferramentas declaradas de forma semântica, permitindo a caracterização da superfície de ataque quando a execução dinâmica é incompleta e permitindo a validação cruzada de riscos de egress declarados contra evidências de tempo de execução.
4. Avaliação Empírica: Uma avaliação abrangente através de sujeitos cross-language controlados, um benchmark de evasão e um corpus de 100 repositórios MCP.

Resultados de Avaliação

Os autores avaliaram o SandScope em três frentes:

1. Benchmarks de Tempo de Execução Controlados

• Sujeitos: 30 sujeitos cross-language (Go, Python, Rust, TypeScript) cobrindo ferramentas benignas, vazamentos de ambiente, exfiltração de arquivos e fixtures de beacon de C2.
• Desempenho: O SandScope alcançou 100% de precisão (0 falsos positivos) e 88,9% de recall (F1 = 0,941).
• Descobertas: Detectou com sucesso 16 verdadeiros positivos onde fontes detentoras de autoridade alcançaram sinks visíveis ao LLM. Os dois falsos negativos ocorreram em casos de beacon de C2 não relacionados ao protocolo, onde a saída não produziu uma testemunha de origem-para-sink recuperável sob as regras de extração atuais.

2. Benchmark de Evasão

• O detector aprimorado (suportando ROT13, Hex, Base64 e fragmentação) identificou com sucesso transformações de baixo esforço que o pareamento de substring bruto perdeu.
• Limitação: O sistema permanece um detector de evidência positiva; ele não afirma completude contra criptografia, compressão, hashing ou reescrita semântica.

3. Corpus do Mundo Real (100 Repositórios)

• Cobertura Dinâmica: O SandScope resolveu 91 repositórios e completou varreduras dinâmicas rasas para 35 (taxa de sucesso de 38,5%). As falhas ocorreram principalmente devido a problemas de build, inicialização ou de protocolo, não devido ao detector em si.
• Exploração Direcionada: Nos 35 repositórios varridos com sucesso, uma passagem de exploração guiada por esquema reexecutou 33 e observou testemunhas de origem-para-sink em 12 repositórios (60 testemunhas no total).
• Perfilamento Semântico: A camada semântica recuperou metadados de nível de ferramenta para 71 repositórios (cobrindo 1.127 ferramentas), incluindo 886 ferramentas com pelo menos uma capacidade declarada sensível à segurança (ex: acesso à rede, acesso ao sistema de arquivos).
• Validação Cruzada: A comparação de capacidades de egress declaradas com evidências de tempo de execução revelou casos onde capacidades foram declaradas mas não exercidas, e casos onde o comportamento de tempo de execução (ex: conexões de saída negadas) foi observado apesar da falta de metadados declarados.

Significância e Alegações

O artigo posiciona o SandScope como o primeiro framework de auditoria comportamental específico para MCP que trata campos de protocolo visíveis ao LLM como sinks de segurança e reporta testemunhas de origem-para-sink em tempo de execução entre servidores MCP não modificados e sujeitos WASI portáteis.

• Alegações Modestas: Os autores afirmam explicitamente que o SandScope não é um motor completo de rastreamento de taint ou um detector de vulnerabilidades autônomo. Ele não infere fluxos arbitrários de transformação ou criptografados.
• Valor Central: Sua contribuição é fornecer evidência prática e auditável para o risco de ferramentas MCP. Ao separar o metadado semântico (capacidades declaradas) das testemunhas de tempo de execução (fluxos observados), ele oferece uma visão em camadas de risco que ajuda a priorizar testes e entender a lacuna entre o que uma ferramenta afirma fazer e o que ela realmente expõe em um cenário de execução específico.
• Reprodutibilidade: O código-fonte é liberado para facilitar a reprodutibilidade, e a estrutura é projetada para funcionar com implementações existentes de MCP sem exigir modificações no código das próprias ferramentas.