Meta ha presentato Muse come un assistente costruito “dalle fondamenta per privacy e sicurezza”. Pochi giorni dopo il lancio, un ricercatore ha trovato una vulnerabilità zero-day che permette a un semplice attacco ClickFix di prendere il controllo completo dell’agente, sfruttando i suoi privilegi elevati su app e terminale. Per chi si occupa di consulenza AI, questo episodio non riguarda solo Meta: riguarda il modo in cui ogni azienda dovrebbe valutare un assistente prima di collegarlo ai propri sistemi. La promessa di sicurezza, da sola, non basta come garanzia.
Perché i privilegi degli assistenti AI vanno misurati, non dichiarati
Il problema di Muse nasce da una scelta di design: l’assistente ha accesso profondo a comandi locali e applicazioni, per poterle gestire in autonomia. Più un agente AI può fare, più superficie di attacco offre. È lo stesso principio che vale per un nuovo dipendente a cui si affidano subito le chiavi di tutti gli uffici: comodo, ma rischioso finché non si conosce il suo comportamento.
Nella consulenza AI alle PMI italiane, questo si traduce in una domanda concreta da porre prima di ogni adozione: quali permessi realmente servono all’assistente per svolgere il suo compito, e quali sono invece concessi per pigrizia di configurazione? Un chatbot che deve rispondere a domande sui prodotti non ha bisogno di accesso al file system aziendale. Un agente che gestisce agende e email non deve necessariamente poter eseguire comandi da terminale. Separare i privilegi per funzione riduce drasticamente il danno potenziale di una singola falla.
La due diligence sugli strumenti AI prima della firma
Molte PMI scelgono un assistente AI guardando soprattutto al prezzo e alla facilità d’uso, lasciando la sicurezza come voce implicita nel contratto col fornitore. Il caso Muse mostra che anche i grandi player possono avere falle serie proprio nei sistemi più privilegiati e più pubblicizzati. Una due diligence seria dovrebbe includere alcune verifiche minime: chi ha accesso ai log delle conversazioni, quali permessi di sistema l’agente richiede di default, se esiste un piano di risposta rapida in caso di vulnerabilità scoperta e con quale tempistica il fornitore comunica gli incidenti.
Un consulente AI che affianca una PMI in questa fase non deve necessariamente essere un esperto di sicurezza informatica. Deve però sapere fare le domande giuste al fornitore e leggere criticamente le risposte, magari coinvolgendo un tecnico quando i permessi richiesti appaiono sproporzionati rispetto al compito. Nella pratica, questo significa anche testare l’assistente in un ambiente isolato prima di collegarlo a dati sensibili, invece di attivarlo direttamente in produzione perché “tanto lo dice il fornitore che è sicuro”.
Vale la pena ricordare che ClickFix, la tecnica usata contro Muse, sfrutta l’inganno dell’utente più che una falla tecnica sofisticata: un link o un comando che sembra innocuo. Formare le persone a riconoscere questi pattern resta complementare a qualsiasi configurazione tecnica, perché la sicurezza di un assistente AI dipende anche da chi lo usa ogni giorno.
Un equilibrio da ricalibrare continuamente
Gli assistenti AI diventeranno più capaci, e con loro cresceranno i privilegi che chiediamo di concedere. Per una PMI italiana, l’insegnamento pratico del caso Muse è che la fiducia in un fornitore va verificata con controlli periodici, non concessa una volta e dimenticata. Rivedere ogni sei mesi quali permessi ha realmente un assistente AI, chiedere aggiornamenti sulle vulnerabilità note e mantenere un canale diretto con il fornitore per le emergenze costano poco rispetto al danno di una violazione. La sicurezza degli agenti AI, più che un requisito tecnico, è un processo che va tenuto vivo nel tempo.
Consulenza AI: il caso Muse di Meta insegna la sicurezza degli agenti
