L’IA può agire quando aggiungi un tool: il test del CERT-AgID e la verifica da fare

Un assistente IA può dare una risposta impeccabile e, nello stesso momento, provare a contattare un sito esterno senza che l’utente glielo abbia chiesto. Non è un allarme generico: è lo scenario riprodotto dal CERT-AgID, il team di risposta agli incidenti dell’Agenzia per l’Italia Digitale, in un paper pubblicato il 4 novembre 2026.

Il punto non è la sola chat. Il rischio emerge quando un modello open-weight, cioè con pesi disponibili per essere eseguiti o adattati localmente, viene trasformato in agente e collegato a strumenti: file aziendali, database, e-mail, browser o servizi interni. In questo contesto MCP, Model Context Protocol, è il meccanismo con cui l’assistente riceve la descrizione degli strumenti che può usare.

Che cosa ha verificato il CERT-AgID

Nel test documentato dal CERT-AgID, un modello Qwen3-1.7B è stato modificato con un adapter LoRA per associare la presenza di un server MCP con un nome preciso a una chiamata verso un URL stabilito in precedenza. La richiesta dell’utente era ordinaria e non riguardava quello strumento: il modello continuava a produrre una risposta plausibile, ma con il server giusto disponibile generava anche una richiesta HTTPS reale.

La condizione non si attivava se il server mancava o se aveva un nome diverso, anche molto simile. È questo l’aspetto più insidioso: il modello o l’adapter potrebbe superare controlli iniziali in un ambiente di prova e comportarsi diversamente soltanto dopo l’aggiunta di un nuovo connettore. Il CERT precisa inoltre che il metodo non è legato a Qwen: il principio può riguardare altri modelli open-weight che supportano il fine-tuning.

I dettagli tecnici sono nel resoconto del CERT-AgID e nel paper originale pubblicato da AgID. Non descrivono una vulnerabilità automatica di ogni assistente o di ogni server MCP: documentano invece una tecnica sperimentale e il controllo che manca quando si giudica un agente soltanto dalla qualità della sua risposta testuale.

Perché è un problema concreto per aziende e PA italiane

In Italia i modelli locali e quelli open-weight vengono scelti spesso per elaborare dati riservati e per integrare sistemi già presenti. Collegare un agente a un archivio documentale o a un applicativo interno può essere utile; significa però consegnargli anche una capacità d’azione. Se il modello, un adapter o una catena di fornitori non sono stati verificati, una chiamata inattesa può esporre metadati, attivare un flusso non previsto o diventare il primo segnale di un problema nella filiera software.

Il tema non resta teorico nel quadro italiano. Nel riepilogo della settimana dal 31 ottobre al 6 novembre, il CERT-AgID ha indicato 217 campagne malevole osservate nel proprio perimetro, 187 delle quali con obiettivi italiani, e ha richiamato esplicitamente il test sulle backdoor nei modelli open-weight. Il bollettino settimanale del CERT-AgID non collega quei numeri alla backdoor sperimentale, ma conferma quanto sia importante trattare con prudenza ogni nuova integrazione.

La verifica pratica prima di collegare un nuovo server MCP

Chi gestisce un assistente con accesso a tool non deve rinunciare agli strumenti, ma cambiare il test di accettazione. Prima del collegamento in produzione conviene usare un ambiente isolato, registrare tutte le azioni e verificare cosa accade anche cambiando nome, descrizione e disponibilità del server. La prova va ripetuta con il modello, gli adapter e i connettori che saranno effettivamente usati: una demo riuscita con una chat pulita non basta.

• Limitare i permessi: ogni tool deve avere soltanto i privilegi necessari, senza token amministrativi o accesso indiscriminato a dati e rete.

• Mettere un controllo fuori dal modello: per invii, cancellazioni, pagamenti, modifiche ai dati e chiamate verso l’esterno serve una regola applicativa o un’approvazione umana; non è prudente affidare la decisione al solo prompt.

• Bloccare e registrare l’uscita in rete: usare un proxy o una lista di destinazioni consentite, con log che permettano di associare ogni chiamata al tool e alla richiesta che l’ha originata.

• Verificare la provenienza: fissare versioni e hash di modello, adapter e server MCP; valutare chi mantiene il progetto e quali modifiche entrano negli aggiornamenti.

• Provare gli scenari negativi: il CERT suggerisce di variare nomi e disponibilità dei server. Aggiungere test con richieste normali è essenziale proprio perché il comportamento anomalo può non dipendere dalla domanda dell’utente.

La lezione del test è semplice: in un agente IA la risposta che si legge non coincide sempre con l’azione che il sistema può compiere. Prima di ampliare l’elenco dei tool, controllare autorizzazioni, rete e log è un passaggio tecnico piccolo rispetto al costo di dover ricostruire dopo che cosa è uscito dall’ambiente.