Ogni server MCP a cui ti connetti invia una risposta tools/list — un documento JSON scritto da chiunque abbia costruito il server — direttamente nel contesto del tuo modello, senza revisione. Incolla quella risposta nello scanner di VeriSwarm e ottieni 11 controlli deterministici in pochi secondi: tool poisoning, typosquatting, manipolazione degli schemi, pattern di rug-pull, prompt injection, permessi eccessivi, model misbinding, context spoofing, canali occulti, riferimenti di memoria non sicuri e header injection. Nessun LLM che giudica i tuoi tool — analisi di pattern e struttura che restituisce sempre lo stesso verdetto.
I metadati di un tool MCP sono strutturali. Il modello decide cosa chiamare e come in base al testo della descrizione — non al codice che c'è dietro. Una descrizione avvelenata non deve compromettere nulla; l'attacco avviene interamente nel ragionamento del modello. Il benchmark MCPTox ha testato questo scenario contro 45 server MCP reali e 353 tool reali, misurando tassi di successo degli attacchi superiori al 60%, con un picco del 72%. Leggere le descrizioni dei tool a occhio non è scalabile oltre il primo server, e non sopravvive a un rug pull — un server che si comporta correttamente durante la tua revisione e distribuisce qualcosa di diverso al successivo aggiornamento di versione.
Coprono le categorie di rischio originali per cui lo scanner è stato costruito — quelle più probabili in una definizione di tool avvelenata o trascurata.
Istruzioni nascoste in descrizioni e testo dei parametri — «ignora le istruzioni precedenti», direttive di occultamento, dirottamenti di persona. Lo scanner percorre l'intero albero dello schema, incluse le proprietà annidate dentro rami oneOf/anyOf, quindi un payload sepolto quattro livelli più in basso emerge comunque.
Nomi di tool sospettosamente simili a tool noti — incluse imitazioni che cambiano solo maiuscole/minuscole, come READ_FILE che si spaccia per read_file, cosa che un confronto esatto e ingenuo non coglie affatto.
Schemi a oggetto vuoti che accettano input arbitrari, additionalProperties: true che lascia passare campi nascosti, e schemi annidati oltre 4 livelli di profondità — un luogo comune per nascondere un parametro malevolo.
Un linguaggio che richiede credenziali, token o accesso a file sensibili ed endpoint di rete interni che lo scopo dichiarato del tool non giustifica — la preparazione per una successiva ridefinizione una volta che il tool è considerato affidabile.
Blob in Base64 che si decodificano in testo leggibile — contrabbando di payload — e omoglifi Unicode, come una а cirillica che sostituisce la tua a, usati per far passare istruzioni oltre una revisione visiva.
Un tool nominato o descritto come di sola lettura che accetta i parametri command, script o sql sta dichiarando una capacità e fornendone un'altra.
Rischi specifici del protocollo che i primi sei non coprono. Tra tutti gli undici controlli, lo scanner copre 9 dei 10 rischi dell'OWASP MCP Top 10 v0.1-beta (2025). Il decimo — MCP08, Lack of Audit and Telemetry — è qualcosa che una definizione statica di tool non può mostrare; è una lacuna di logging a runtime, non di schema.
Tool codificati rigidamente per un modello specifico — «funziona solo con GPT-4» oppure un requisito di accoppiamento con un system prompt. Crea una dipendenza di instradamento e una superficie di attacco specifica per quel modello.
Un tool che afferma di poter riscrivere la cronologia della conversazione, iniettare turni falsi o impersonare l'utente o l'assistente — capacità che possono neutralizzare sia i filtri di sicurezza sia le tracce di audit.
Chiavi di primo livello non standard, campi di schema di estensione del fornitore (x-) e lunghi blob in base64 incorporati nelle descrizioni — luoghi dove un revisore che cerca testo discorsivo non guarderà.
Un linguaggio che rivendica accesso a stato globale, condiviso o tra sessioni, oppure un parametro session_id con un carattere jolly come valore predefinito — lo schema tipico dietro una rottura dell'isolamento tra tenant.
Un parametro con la forma di un nome di header — tra cui authorization, cookie o host — oppure uno collegato a una richiesta in uscita tramite l'estensione x-mcp-header della specifica MCP. Entrambi possono sovrascrivere un header di confine di fiducia che chi chiama non vede mai.
Gli stessi 11 controlli, lo stesso formato di report, tre modi per farlo:
POST /v1/suite/guard/scan-mcp con le definizioni dei tool nel corpo della richiesta. Restituisce un verdetto (pass / warn / fail), un punteggio di rischio 0-1 e un array di risultati — ogni risultato riporta il nome del tool, il controllo che si è attivato, la gravità, le prove e una raccomandazione.scanMcpTools() nell'SDK Node, scan_mcp_tools() nell'SDK Python — entrambi incapsulano lo stesso endpoint con forme di richiesta/risposta tipizzate.scan_mcp_tools sul server MCP stesso di VeriSwarm gli consente di scansionare i tool di un altro server prima ancora di chiamarli — senza bisogno di un client HTTP separato.I risultati con gravità critica o alta vengono salvati come risultati di scansione Guard sul tuo tenant, quindi un risultato di scansione non è una stampa a console una tantum — è un registro che puoi rivedere, dare priorità e chiudere nel tempo.
Una definizione di tool scansionata pulita oggi può distribuire qualcosa di diverso domani — la proprietà che definisce un rug pull è proprio che la versione che hai controllato non è la versione che eseguirai la settimana prossima. Esegui la scansione a ogni aggiornamento di versione del server MCP, o secondo una pianificazione, non solo alla prima connessione. Lo scanner è la metà pre-deployment della storia; la metà a runtime — che filtra le chiamate ai tool in tempo reale man mano che avvengono, dopo che il server ha già superato una scansione — è Guard Proxy. Nessuno dei due sostituisce l'altro: lo scanner rileva ciò che un tool dichiara, Guard Proxy rileva ciò che fa.
Il tool poisoning è il controllo che vale più la pena capire in profondità — è quello in cui l'attacco avviene interamente nel ragionamento del modello, senza nulla da intercettare a livello di rete. La meccanica dell'attacco, i tassi di successo reali e come lo scanner lo rileva sono descritti nell'approfondimento dedicato: MCP Tool Poisoning: come funziona l'attacco e come rilevarlo.
Chiama il suo metodo tools/list per ottenere le definizioni dei tool, poi invia quell'array allo scanner di VeriSwarm — POST /v1/suite/guard/scan-mcp, lo scanMcpTools() dell'SDK Node, lo scan_mcp_tools() dell'SDK Python, oppure il tool scan_mcp_tools del server MCP ospitato. Tutti e quattro chiamano lo stesso motore a 11 controlli e restituiscono lo stesso report strutturato: un verdetto (pass/warn/fail), un punteggio di rischio 0-1 e, per ogni risultato, gravità, prove e una raccomandazione.
Undici controlli deterministici: tool poisoning, typosquatting, manipolazione degli schemi, pattern di rug-pull, prompt injection e permessi eccessivi coprono le sei categorie di rischio originali; model misbinding, context spoofing, canali occulti, riferimenti di memoria non sicuri e header injection allineano lo scanner a 9 dei 10 rischi dell'OWASP MCP Top 10 v0.1-beta (2025) — tutti i rischi tranne MCP08 (Lack of Audit and Telemetry), che non è qualcosa che una definizione statica di tool può mostrarti; serve il logging a runtime, non una scansione dello schema. Ogni controllo si basa su pattern e struttura — nessun LLM nel ciclo, quindi una data definizione di tool produce sempre gli stessi risultati ogni volta che la scansioni.
No. È un analizzatore statico — pattern regex, percorsi dell'albero dello schema e normalizzazione Unicode, non una chiamata a un modello. È un compromesso deliberato: i giudici probabilistici sono il motivo per cui almeno un audit indipendente di uno scanner MCP basato su YARA ha riportato un tasso di falsi positivi di circa il 78%. I controlli deterministici sacrificano un po' di recall in cambio di qualcosa su cui una pipeline CI può realmente basare un gate — lo stesso input produce due volte lo stesso verdetto.
Entrambi. In CI, salva la risposta tools/list di un server in un file e scansionala come step della pipeline — un risultato critico è una build che fallisce, non un thread su Slack dopo il fatto. In produzione, chiama l'endpoint API secondo una pianificazione o a ogni aggiornamento di versione del server MCP, perché un tool che ha superato la scansione pulito una volta è considerato affidabile solo per quella volta. Ripetere la scansione è il modo in cui un rug-pull — un server che si comporta bene durante la revisione e diventa malevolo in seguito — viene individuato invece che ignorato.
Lo scanner è la metà pre-deployment: legge le definizioni dei tool dichiarate prima che il tuo agente chiami mai il server. Guard Proxy è la metà a runtime: si posiziona tra il tuo agente e i suoi tool, filtrando ogni chiamata live man mano che avviene. Nessuno dei due sostituisce l'altro. Lo scanner rileva ciò che un tool dichiara di fare; Guard Proxy rileva ciò che fa realmente al momento della chiamata.
È misurato, non teorico. Il benchmark MCPTox ha testato il tool poisoning contro 45 server MCP reali e 353 tool reali, trovando tassi di successo degli attacchi superiori al 60%, con un picco al 72% — con i modelli più capaci che obbediscono più spesso, perché seguire meglio le istruzioni significa anche rispettare meglio un'istruzione malevola. Un approfondimento completo sulla meccanica dell'attacco e su come il controllo tool_poisoning dello scanner lo rileva si trova nella spiegazione dedicata.
Invia una risposta tools/list a Guard e scopri cosa hanno letto finora i tuoi agenti. Il piano gratuito di Gate ti dà per primo la pipeline di trust scoring ed eventi; lo scanner di Guard si basa su di essa.