Nuove ricerche dimostrano che il Model Context Protocol (MCP) — l'interfaccia che consente agli agenti basati su modelli linguistici di grandi dimensioni (LLM) di chiamare strumenti esterni — può essere dirottato attraverso attacchi di “tool-poisoning” che hanno successo in più di un terzo dei casi. Su 20 agenti popolari, il tasso di successo medio è stato del 36,5%; il modello o1-mini è caduto nel 72,8% dei tentativi, mentre Claude-3.7-Sonnet ha rifiutato le chiamate malevole in meno del 3% dei casi. Per chiunque implementi agenti LLM che si affidano a MCP, queste scoperte trasformano una funzione di comodità in un rischio per la supply chain che può essere sfruttato prima ancora che venga eseguito qualsiasi codice.

Perché MCP è importante per gli sviluppatori oggi

MCP standardizza il modo in cui gli agenti scoprono, registrano e invocano strumenti come lettori di file, API web o inviatori di email. Pubblicando il nome di uno strumento, lo schema di input e una breve descrizione, un server rende la funzionalità disponibile a qualsiasi client che comprenda il protocollo. La promessa è semplice: un agente può cercare uno strumento, inviare una richiesta e ricevere una risposta senza dover codificare manualmente ogni singola integrazione.

Questa flessibilità crea anche una relazione di fiducia implicita. La specifica indica ai client di trattare le descrizioni degli strumenti come affidabili solo se provengono da un server di cui il client si fida già. Il nuovo studio dimostra che questa fiducia può essere abusata.

In cosa il tool-poisoning differisce dalla comune prompt injection

La prompt injection tradizionale inserisce istruzioni malevole nel testo che il modello genera o riceve durante l'esecuzione. Il modello segue quindi tali istruzioni perché appaiono nello stesso flusso di token della richiesta dell'utente.

Al contrario, il tool-poisoning nasconde il payload nei metadati dello strumento — il nome, la descrizione o lo schema dei parametri che vengono registrati prima di qualsiasi chiamata dell'agente. Quando un agente seleziona successivamente lo strumento, tratta la descrizione come parte del “contesto affidabile” e potrebbe seguire l'istruzione nascosta senza alcun controllo durante l'esecuzione. Poiché l'iniezione avviene durante la registrazione, non esiste alcun punto nel flusso di esecuzione in cui il modello possa segnalare il payload come sospetto.

L'entità del problema – il benchmark MCPTox

I ricercatori dietro MCPTox (arXiv:2508.14925) hanno valutato 45 server MCP che offrono un totale di 353 strumenti distinti. Hanno creato script di attacco contro 20 agenti LLM ampiamente utilizzati, misurando la frequenza con cui gli agenti eseguivano la chiamata allo strumento avvelenato.

  • Tasso di successo medio: 36,5%
  • Picco di successo: o1-mini al 72,8%
  • Miglior rifiuto: Claude-3.7-Sonnet, ancora sotto il 3%

I numeri rivelano una realtà cruda: la maggior parte degli agenti non rifiuta una chiamata avvelenata perché la richiesta appare come un'invocazione legittima dello strumento. Gli agenti presumono che la descrizione dello strumento sia un frammento innocuo di documentazione, non un vettore per l'esecuzione di codice.

Perché gli agenti raramente rifiutano le chiamate avvelenate

La linea guida LLM01 di OWASP spiega che gli LLM non distinguono tra istruzioni e dati: entrambi sono solo token in una sequenza. Quando una descrizione dello strumento dice “invia un'email a admin@example.com con oggetto ‘Update’”, il modello non può distinguere se quella riga sia un commento innocuo o un'istruzione da obbedire in seguito. Di conseguenza, il modello tratta la descrizione come parte dell'ambiente affidabile e segue qualsiasi comando incorporato quando lo strumento viene invocato.

Linee guida esistenti e loro lacune

La specifica MCP consiglia già ai client di trattare le descrizioni degli strumenti come non affidabili, a meno che non provengano da un server fidato, e di mantenere un essere umano nel processo (human in the loop) per le chiamate ad alto impatto. Il benchmark mostra che molte implementazioni nel mondo reale ignorano o interpretano in modo superficiale queste raccomandazioni.

Passaggi concreti che gli sviluppatori possono intraprendere oggi

  1. Fissa le versioni del server – Fai riferimento a un'immagine o a un hash del server specifico e immutabile, invece di un tag variabile. Questo impedisce a un attaccante di sostituire un registro pulito con uno avvelenato dopo il deployment.
  2. Inizia con una allowlist vuota – Abilita solo gli strumenti che sono stati esplicitamente verificati. Tutto ciò che non è presente nell'elenco viene bloccato per impostazione predefinita.
  3. Controlla gli strumenti che modificano lo stato – Richiedi un'approvazione aggiuntiva per qualsiasi strumento che scriva, invii o elimini dati. Separa le capacità di tipo "sola lettura" da quelle "con capacità di scrittura" nello schema.
  4. Aggiungi l'approvazione umana per le chiamate ad alto impatto – Per le azioni che potrebbero influenzare sistemi esterni (ad es. invio di email, esecuzione di comandi, modifica di file), richiedi l'intervento di un revisore umano prima che la chiamata venga inviata.
  5. Registra ogni invocazione degli strumenti – Registra il nome dello strumento, gli argomenti, il timestamp e l'agente di origine. Una traccia di audit immutabile rende possibile l'analisi post-mortem e può scoraggiare gli attaccanti che sanno che le loro azioni saranno visibili.

Tratta ogni descrizione dello strumento come codice sorgente — soggetto a linting, code review e controllo di versione — per allineare la supply chain MCP alle pratiche standard di sviluppo software.

Controargomentazioni e domande aperte

Il benchmark, tuttavia, mostra che anche il modello più avanzato dello studio ha rifiutato meno del tre percento delle chiamate avvelenate. Il fine-tuning può migliorare il rilevamento, ma non può garantire la sicurezza contro nuovi payload incorporati in campi dello schema che il modello non ha mai visto.

Cosa monitorare in futuro

  • Standard emergenti – Monitora le proposte della comunità di sicurezza LLM per richiedere firme crittografiche sugli schemi degli strumenti.
  • Rinforzo del registro degli strumenti – I fornitori potrebbero iniziare a offrire registri immutabili e di sola lettura come servizio, riducendo la superficie di attacco.
  • Difese a livello di modello – La ricerca su tecniche di prompting o modelli ausiliari che segnalano metadati sospetti degli strumenti potrebbe integrare le protezioni lato host.

La conclusione pratica è chiara: qualsiasi deployment basato su MCP dovrebbe sottoporre le descrizioni degli strumenti a un audit con lo stesso rigore applicato alle librerie di terze parti. Ignorare il rischio della supply chain trasforma un'astrazione comoda in una backdoor silenziosa. Fissando i server, imponendo allowlist basate sul principio del minimo privilegio, controllando le azioni che modificano lo stato, coinvolgendo gli umani dove necessario e mantenendo un log immutabile, gli sviluppatori possono evitare che i loro agenti LLM diventino complici involontari.