Backdoor nei modelli open-weight: il ruolo di MCP

In breve: Il test CERT-AGID mostra un comportamento appreso che si attiva quando l’agente vede uno specifico server MCP. Il modello propone la chiamata, ma è il software circostante a eseguirla con i propri permessi. Il caso è sperimentale: non dimostra una campagna reale né rende insicuri tutti i modelli open-weight. Backdoor nei modelli open-weight.

Verifica documentale della pagina ufficiale CERT-AGID del 4 novembre 2026 e lettura integrale del testo del PDF collegato, composto da 11 pagine. I risultati sono stati confrontati con descrizione del metodo, tabella dei controlli e conclusioni. I riferimenti di pagina usano la posizione fisica nel PDF. Non abbiamo addestrato modelli, replicato l’esperimento o collaudato le contromisure; i consigli operativi restano indicazioni da verificare nel proprio ambiente.

• La prova usa Qwen3-1.7B e due adapter LoRA con compiti distinti. CERT-AGID, ricerca
• Con il server previsto: sei richieste su sei; senza server o con nome neutro: zero su sei per condizione. CERT-AGID, ricerca
• I casi positivi ripetono lo stesso contesto operativo del decisore: non sono conversazioni indipendenti. CERT-AGID, ricerca
• La distribuzione successiva del server è uno scenario ipotetico, non un incidente documentato. CERT-AGID, ricerca

Come si attiva il comportamento appreso?

Il CERT-AGID ha studiato Qwen3-1.7B con due adapter LoRA, cioè parametri aggiuntivi addestrati senza modificare i pesi originali. Un adapter produce la risposta; l’altro valuta gli strumenti disponibili e decide se richiamarli, senza vedere la domanda iniziale. Il comportamento condizionale riguarda quindi l’ambiente, non una frase segreta scritta dall’utente. Serve però più di un nome: devono esserci uno strumento compatibile e un’applicazione che ne permetta l’esecuzione. I pesi generano una proposta di azione; non aprono autonomamente una connessione. Questa distinzione evita di attribuire al modello capacità che dipendono dall’infrastruttura. La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP.

Che cosa dimostrano i numeri del test?

Nel confronto con il server reale, la condizione prevista ha prodotto sei chiamate su sei, tutte con risposta HTTP 200. Senza server o con un nome neutro, le chiamate sono state zero su sei in ciascuna condizione. Le risposte alle domande erano riutilizzate e il decisore non vedeva quelle domande: i sei casi positivi ripetevano lo stesso contesto operativo. Il dato mostra ripetibilità nel banco di prova, non una probabilità di attacco nel mondo reale. Anche i 37 esiti attesi su 37 controlli offline restano un risultato di quel test, non una certificazione generale. La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP.

È stata osservata una distribuzione malevola?

Il documento descrive una possibile distribuzione in due tempi: prima un modello o un adapter, poi il server che ne soddisfa la condizione di attivazione. Cita Hugging Face come piattaforma dello scenario, non come luogo di una campagna osservata. Non viene presentata una diffusione reale di questo modello né una compromissione di utenti. La domanda utile per chi acquista o integra questi componenti è quindi organizzativa: chi controlla l’abbinamento fra versione del modello, adapter e strumenti autorizzati? Un collaudo iniziale non copre automaticamente le combinazioni introdotte in seguito. La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP.

Perché cercare l’URL nei file non basta?

Nel PDF, la ricerca letterale dell’indirizzo nei file degli adapter non lo trova. Questo non rende la backdoor invisibile e non prova che ogni altro controllo sui pesi sia inutile. L’indirizzo può essere prodotto durante l’inferenza senza comparire come una stringa continua nei file. Quando la chiamata viene generata, invece, destinazione e argomenti sono osservabili dal client MCP e dal server. Per chi valuta un agente, la conseguenza pratica è affiancare alle verifiche dei file una traccia delle azioni, senza scambiare una scansione testuale negativa per un via libera. La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP.

Quali controlli valutare prima di collegare un tool?

Per un’integrazione aziendale, il controllo utile sta prima dell’esecuzione: permessi minimi, destinazioni ammesse e verifica che l’azione sia coerente con il compito. Una destinazione autorizzata non rende lecita qualunque richiesta. Nei test isolati, osserva anche le chiamate tentate, usando dati sintetici ed evitando informazioni personali nei log. Quando cambia il catalogo degli strumenti, ripeti le verifiche con compiti innocui; per azioni sensibili valuta un’approvazione umana preventiva. Sono misure da collaudare nel proprio ambiente, non un rimedio già validato contro questa backdoor: il documento richiede una verifica dedicata della loro efficacia. La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP.

Condizioni e limitazioni

Il confronto di rete comprende 18 valutazioni della decisione MCP, non 18 conversazioni indipendenti. Le sei risposte iniziali sono riutilizzate; i sei casi positivi ripetono lo stesso contesto per l’adapter che decide la chiamata. La distribuzione su Hugging Face seguita dall’arrivo del server è uno scenario ipotetico. Non vengono dimostrate una campagna reale, una compromissione diffusa o l’efficacia generale delle contromisure suggerite.

Checklist pratica

• Per ogni test, annota versione del modello, adapter e catalogo degli strumenti autorizzati: servono a distinguere quale combinazione hai effettivamente valutato.
• In un ambiente isolato, usa richieste innocue e dati sintetici; confronta le azioni tentate quando cambiano disponibilità e metadati dei tool, senza riprodurre payload di backdoor.
• Prima dell’esecuzione, controlla con regole esterne al modello strumento, destinazione e coerenza con il compito; un indirizzo ammesso non autorizza ogni azione.
• Limita permessi dei tool e accesso di rete alle esigenze del compito. Non usare credenziali di produzione o dati personali nelle prove.
• Registra le chiamate tentate e il loro esito con metadati minimi; per osservare gli argomenti usa soltanto dati sintetici, senza conservare segreti o informazioni personali.
• Per azioni sensibili o estranee al compito, valuta un’approvazione preventiva che mostri strumento, destinazione ed effetto previsto, evitando di esporre dati riservati.
• Ripeti le verifiche dopo cambiamenti a modello, adapter o strumenti. Documenta i casi coperti e quelli esclusi: nessuna anomalia osservata non significa assenza di trigger sconosciuti.

Fonti primarie

• Backdoor nei modelli open-weight
• La backdoor attende il suo turno. Un comportamento appreso nei pesi attivato dalla presenza di un server MCP