Sintesi Tecnica: MCP-SandboxScan (SandScope)

Definizione del Problema

Il Model Context Protocol (MCP) consente agli agenti LLM di invocare strumenti esterni e accedere a sorgenti dati, creando una nuova superficie di attacco nella supply-chain del software. Sebbene gli strumenti vengano installati come pacchetti di terze parti, i loro output entrano spesso nel contesto di ragionamento dell'agente. Questa architettura introduce un rischio di "confused deputy" (deputato confuso): input controllati da un attaccante (ad esempio, tramite argomenti generati da un LLM, pagine web recuperate o metadati di repository) possono indurre strumenti altrimenti benigni o fidati a esercitare un'autorità legittima su file locali, variabili d'ambiente o operazioni di rete. Il pericolo critico è che questi strumenti possano restituire contenuti sensibili o simili a istruzioni in campi visibili all'LLM, esponendo efficacemente segreti o iniettando istruzioni nel passaggio di ragionamento successivo dell'agente.

Gli approcci di sicurezza esistenti sono insufficienti perché:

1. L'ispezione statica delle descrizioni degli strumenti o del codice sorgente non può rilevare comportamenti che si manifestano solo a runtime (ad esempio, l'accesso a file offuscati o segreti derivati dalla lettura di file a runtime).
2. Il monitoraggio basato su proxy del traffico spesso non riesce a catturare i comportamenti interni dei processi degli strumenti o il flusso specifico di dati dagli input esterni agli output visibili all'LLM.
3. L'esecuzione diretta di strumenti di terze parti sull'host è insicura a causa dei privilegi ampi che questi strumenti spesso ereditano.

Esiste una lacuna nell'osservabilità e nel contenimento a runtime: gli auditor hanno bisogno di osservare i flussi dagli input esterni agli output visibili all'LLM senza concedere agli strumenti non fidati un'autorità illimitata sull'host.

Metodologia: Framework SandScope

Gli autori propongono SandScope, un framework di audit consapevole di MCP che combina l'esecuzione controllata con il rilevamento di testimoni a runtime e il profiling semantico degli strumenti. Opera senza assumere che il codice dello strumento sia malevolo, concentrandosi invece sul comportamento di "confused deputy" indotto da input esterni.

1. Backend di Esecuzione

SandScope supporta due percorsi di esecuzione per bilanciare contenimento e fedeltà al protocollo:

• Percorso Sandbox WASI: Per strumenti portatili (artefatti WebAssembly o quelli avvolti in leggeri adapter), SandScope li esegue sotto l'interfaccia WebAssembly System Interface (WASI). Ciò conferisce capacità esplicite e limitate (ad esempio, variabili d'ambiente specifiche, directory di dati pre-aperte) e nega l'accesso alla rete per impostazione predefinita.
• Percorso Nativo stdio: Per server MCP non modificati (Node.js, Python, Go, ecc.), SandScope pilota il server tramite l'input/output standard. Sebbene ciò preservi la fedeltà del protocollo, si affida a un sandboxing esterno a livello di sistema operativo (ad esempio, Docker, Bubblewrap) per il contenimento.

2. Pipeline di Evidenza

Il framework segue una pipeline a sei stadi:

1. Configurazione della Sorgente di Audit: SandScope inserisce valori "canarino" distinguibili nelle variabili d'ambiente, nelle directory dei file e negli argomenti delle chiamate agli strumenti. Traccia inoltre i segnali di intento di rete (ad esempio, stringhe che suggeriscono richieste in uscita).
2. Scoperta e Adattamento del Target: Identifica il target (artefatto portabile vs server nativo) e seleziona il percorso di esecuzione appropriato. Per i server nativi, esegue una scansione superficiale per recuperare i metadati tools/list.
3. Esecuzione Controllata: Il target viene eseguito. Per i server nativi, un driver inizializza il protocollo, richiede le liste degli strumenti e invoca gli strumenti.
4. Monitoraggio a Runtime: Il sistema registra stdout/stderr limitati, codici di uscita, trascrizioni MCP (JSON-RPC) ed eventi di sandbox (ad esempio, connessioni negate).
5. Estrazione dei Sink: SandScope identifica i sink visibili all'LLM — regioni testuali probabilmente re-inserite nel prompt dell'agente. Questi includono:
   • Linee contenenti marcatori di prompt (ad esempio, PROMPT:).
   • Campi prompt o messages nelle risposte JSON.
   • Nodi foglia con valore stringa nei ritorni strutturati degli strumenti.
6. Rilevamento dei Testimoni (Witness Detection): Il sistema confronta i canarini sorgente con i sink estratti. Utilizza un rilevatore di evidenza positiva che controlla:
   • Sottostringhe esatte.
   • Finestre di prefisso/suffisso (per catturare leak parziali come le chiavi API).
   • Forme normalizzate e decodificate (gestendo ROT13, Hex, Base64 e la frammentazione dei separatori).

3. Profiling Semantico

Per affrontare i casi in cui l'esecuzione dinamica fallisce (a causa di errori di build, credenziali mancanti o stati complessi), SandScope include uno strato semantico. Estrae le capacità dichiarate da:

• Risposte tools/list a runtime.
• Registrazioni statiche a livello di sorgente (ad esempio, decoratori, definizioni di funzioni).
• Metadati del repository (README).
  Questo strato caratterizza la superficie di attacco (ad esempio, "accesso alla rete", "accesso al file system") e dà priorità agli strumenti per i test, anche se non possono essere eseguiti dinamicamente.

Contributi Chiave

1. Definizione dei Sink di Sicurezza MCP: Gli autori definiscono formalmente i campi di risposta MCP visibili all'LLM (risultati degli strumenti, campi prompt/messaggi, payload strutturati) come sink di sicurezza a livello di protocollo e inquadrano l'esposizione dall'esterno al sink come un rischio a runtime.
2. Pipeline di Audit a Runtime Guidata da Scenari: Un sistema che esegue strumenti sotto WASI o pilota server stdio nativi, collegando le sorgenti (ambiente, file, input degli strumenti) ai sink visibili all'LLM tramite testimoni verificabili in una scatola nera, registrando separatamente le evidenze di intento di rete.
3. Profiling Semantico Complementare: Un metodo per recuperare le capacità dichiarate degli strumenti dai metadati e dalle registrazioni statiche, consentendo la caratterizzazione della superficie di attacco quando l'esecuzione dinamica è incompleta e permettendo la validazione incrociata dei rischi di egress dichiarati rispetto alle evidenze a runtime.
4. Valutazione Empirica: Una valutazione completa attraverso soggetti cross-linguaggio controllati, un benchmark di evasione e un corpus di 100 repository MCP.

Risultati della Valutazione

Gli autori hanno valutato SandScope su tre fronti:

1. Benchmark di Runtime Controllati

• Soggetti: 30 soggetti cross-linguaggio (Go, Python, Rust, TypeScript) che coprono strumenti benigni, leak di ambiente, esfiltrazione di file e fixture di C2-beacon.
• Performance: SandScope ha raggiunto una precisione del 100% (0 falsi positivi) e una recall dell'88,9% (F1 = 0,941).
• Risultati: Ha rilevato con successo 16 veri positivi in cui le sorgenti dotate di autorità hanno raggiunto i sink visibili all'LLM. I due falsi negativi si sono verificati in casi di C2-beacon non legati al protocollo, dove l'output non ha prodotto un testimone sorgente-verso-sink recuperabile secondo le attuali regole di estrazione.

2. Benchmark di Evasione

• Il rilevatore potenziato (che supporta ROT13, Hex, Base64 e chunking) ha identificato con successo trasformazioni di basso livello che il semplice matching di sottostringhe aveva mancato.
• Limitazione: Il sistema rimane un rilevatore di evidenza positiva; non pretende la completezza contro crittografia, compressione, hashing o riscrittura semantica.

3. Corpus del Mondo Reale (100 Repository)

• Copertura Dinamica: SandScope ha risolto 91 repository e completato scansioni dinamiche superficiali per 35 (tasso di successo del 38,5%). I fallimenti sono stati dovuti principalmente a problemi di build, avvio o inizializzazione del protocollo, non al rilevatore stesso.
• Esplorazione Mirata: Sui 35 repository scansionati con successo, un passaggio di esplorazione guidato dallo schema ha ri-eseguito 33 soggetti e ha osservato testimoni sorgente-verso-sink in 12 repository (60 testimoni totali).
• Profiling Semantico: Il livello semantico ha recuperato i metadati a livello di strumento per 71 repository (coprendo 1.127 strumenti), inclusi 886 strumenti con almeno una capacità dichiarata sensibile alla sicurezza (ad esempio, accesso alla rete, accesso al file system).
• Validazione Incrociata: Il confronto tra le capacità di egress dichiarate e le evidenze a runtime ha rivelato casi in cui le capacità erano dichiarate ma non esercitate, e casi in cui il comportamento a runtime (ad esempio, connessioni in uscita negate) è stato osservato nonostante la mancanza di metadati dichiarati.

Significato e Claim

Il paper posiziona SandScope come il primo framework di audit comportamentale specifico per MCP che tratta i campi del protocollo visibili all'LLM come sink di sicurezza e riporta testimoni a runtime da sorgente a sink attraverso server MCP non modificati e soggetti portatili WASI.

• Claim Modesti: Gli autori dichiarano esplicitamente che SandScope non è un motore completo di taint-tracking né un rilevatore di vulnerabilità autonomo. Non inferisce flussi arbitrari trasformati o criptati.
• Valore Centrale: Il suo contributo è fornire un'evidenza pratica e verificabile del rischio degli strumenti MCP. Separando i metadati semantici (capacità dichiarate) dalle evidenze a runtime (flussi osservati), offre una visione stratificata del rischio che aiuta a dare priorità ai test e a comprendere il divario tra ciò che uno strumento afferma di fare e ciò che effettivamente espone in uno specifico scenario di esecuzione.
• Riproducibilità: Il codice sorgente è rilasciato per facilitare la riproducibilità, e il framework è progettato per lavorare con le implementazioni MCP esistenti senza richiedere modifiche al codice degli strumenti stessi.