Quando l’assistente AI obbedisce all’attaccante: il caso EchoLeak - Agenda Digitale

Nel giugno del 2025 è stata resa pubblica una vulnerabilità di Microsoft 365 Copilot, catalogata come CVE-2025-32711 e battezzata “EchoLeak”, che ha ottenuto un punteggio di gravità CVSS di 9,3 su una scala che si ferma a 10. Microsoft l’ha corretta lato server prima della divulgazione e ha confermato che non risultava sfruttamento in attacchi reali, ma il meccanismo che l’incidente ha portato alla luce è ciò che merita attenzione, perché ridefinisce la natura stessa di cosa significhi violare un sistema informatico nell’era dell’intelligenza artificiale.Indice degli argomenti

Come funziona EchoLeakEchoLeak Microsoft 365 Copilot e il rischio della prompt injection indirettaCosa è cambiato rispetto a un anno faPerché gli attacchi agli agenti AI sono diventati scalabiliCosa rischia concretamente un’organizzazionePerché le difese tradizionali non bastano contro EchoLeakCosa può fare oggi un’organizzazioneConclusioniCome funziona EchoLeakIl funzionamento di EchoLeak può essere descritto in pochi passaggi. Un attaccante invia all’indirizzo aziendale della vittima una semplice email, scritta in modo da apparire del tutto innocua in modo da non insospettire i filtri ma quella email contiene istruzioni nascoste rivolte all’assistente AI. La vittima non deve aprirla, non deve cliccare su nulla, non deve nemmeno accorgersi che è arrivata: per questo l’attacco è stato classificato come zero-click, il primo zero-click documentato contro un agente AI. Nel momento in cui il dipendente, in un qualsiasi momento successivo, pone una domanda a Copilot, l’assistente esegue il suo normale processo di consultazione delle informazioni aziendali, recupera anche la mail avvelenata insieme agli altri contenuti pertinenti, legge le istruzioni nascoste e le esegue come se fossero state impartite dal proprietario del sistema.Il risultato è l’esfiltrazione automatica verso un server esterno controllato dall’attaccante di tutto ciò che Copilot può raggiungere all’interno dell’organizzazione, ovvero file su OneDrive, documenti su SharePoint, conversazioni su Teams, cronologie di chat e dati preconfigurati nell’ambiente aziendale.EchoLeak Microsoft 365 Copilot e il rischio della prompt injection indirettaQuesto tipo di attacco si chiama Indirect Prompt Injection ed è oggi classificato dall’OWASP, l’organizzazione internazionale di riferimento per la sicurezza applicativa, ai vertici delle minacce specifiche per le applicazioni basate su modelli linguistici. Il punto da fissare per chi guida un’organizzazione è che EchoLeak non è un caso isolato né un bug particolare di un prodotto specifico, ma la prima dimostrazione pratica di una superficie d’attacco strutturale che riguarda qualsiasi assistente AI integrato con le fonti di dati aziendali.Microsoft ha corretto quella singola implementazione, ma il meccanismo che l’ha resa possibile è presente in ogni sistema costruito sullo stesso paradigma, ovvero in tutti gli strumenti che le aziende italiane stanno adottando in questo momento per recuperare produttività su email, documenti e ticketing. È un perimetro di rischio che gli strumenti di sicurezza tradizionali non vedono, perché non c’è codice malevolo da rilevare e non c’è comportamento anomalo da bloccare, e che fino a poco tempo fa era considerato una preoccupazione teorica. Oggi non lo è più.Cosa è cambiato rispetto a un anno faPer anni la sicurezza dei modelli linguistici è stata trattata come un problema di chi parla con il chatbot. La preoccupazione era l’utente furbo che cercava di estorcere all’assistente informazioni che non avrebbe dovuto dare, magari fingendo di essere un ricercatore o costruendo prompt creativi. Era un problema circoscritto, gestibile con filtri all’ingresso e con un po’ di buon senso nella configurazione del sistema. Per chi prendeva decisioni di alto livello in azienda non era una questione strategica.Quel mondo è finito in quanto i sistemi AI di nuova generazione non lavorano più isolati ma sono integrati con le fonti di dati aziendali, leggono email, consultano documenti su SharePoint, accedono a basi di conoscenza interne, eseguono azioni attraverso API (Application Programming Interface). Si chiamano sistemi Retrieval-Augmented Generation, abbreviati in RAG, e nei casi più evoluti agenti AI, capaci non solo di rispondere ma di compiere operazioni nel mondo reale. Microsoft 365 Copilot è esattamente uno di questi sistemi, ed è il motivo per cui EchoLeak ha funzionato. Questa è l’architettura che le aziende italiane stanno adottando in massa per aumentare la produttività, ed è esattamente l’architettura che apre la nuova superficie di attacco.Il concetto da comprendere è semplice. Quando un assistente AI legge una email o un documento, dal suo punto di vista il contenuto di quel testo è materiale da elaborare allo stesso modo delle istruzioni che ha ricevuto dal proprio amministratore. Non distingue tra ciò che gli è stato detto di fare e ciò che trova scritto nelle fonti che consulta. Un attaccante può infilare istruzioni operative all’interno di un contenuto qualsiasi, magari nascoste in testo invisibile o sotto forma di metadati, sapendo che prima o poi l’assistente le incontrerà e le eseguirà. EchoLeak ha funzionato esattamente così, e ciò che lo rende rilevante non è la sofisticazione tecnica ma la banalità del vettore: un’email.Perché gli attacchi agli agenti AI sono diventati scalabiliFino a poco tempo fa si poteva obiettare che questi attacchi, per quanto teoricamente possibili, fossero difficili da realizzare nella pratica. Il motivo è che un assistente AI, prima di leggere un documento, deve sceglierlo tra migliaia o milioni di documenti disponibili, e la probabilità che quello avvelenato venisse selezionato era considerata trascurabile. Un assunto rassicurante che oggi è superato.La ricerca degli ultimi mesi ha dimostrato che un attaccante può costruire un documento progettato specificamente per essere selezionato con altissima probabilità in risposta a una determinata domanda della vittima, e che il costo di questa costruzione è di circa ventun centesimi di dollaro. Per capire perché un costo così basso renda il problema strategicamente diverso da prima, vale la pena fermarsi un momento a spiegare per cosa esattamente si pagano quei centesimi, perché non è un dettaglio tecnico ma è il cuore della questione.L’attaccante affitta per qualche minuto la potenza di calcolo delle stesse piattaforme AI commerciali che usano tutti, quelle di OpenAI, Google, Anthropic e altri provider cloud, attraverso le normali API a pagamento aperte a chiunque abbia una carta di credito. Il documento avvelenato non viene scritto a mano ma viene costruito da un algoritmo automatico che procede per tentativi: parte da una bozza che contiene l’istruzione malevola, la sottopone all’AI per misurare quanto quel testo risulti matematicamente vicino alla domanda che la vittima farà al proprio assistente, modifica leggermente le parole, ritesta, modifica ancora. Questo ciclo viene ripetuto centinaia o migliaia di volte fino a quando il documento ha raggiunto un punteggio di rilevanza tale da garantirgli di essere selezionato dal sistema della vittima con certezza quasi assoluta.Ogni singola chiamata all’API costa frazioni di millesimo di dollaro in quanto elaborare un breve testo è un’operazione banale per chi vende capacità di calcolo a tariffe industriali. Anche con migliaia di iterazioni, il totale rimane intorno ai ventun centesimi.Questo dato cambia la natura del problema, perché significa che la barriera economica all’esecuzione di attacchi mirati e personalizzati contro singole aziende è praticamente azzerata. Qualsiasi attore con motivazioni anche modeste, dal concorrente sleale al cybercriminale di livello medio, può oggi condurre campagne mirate con un budget alla portata di chiunque.Cosa rischia concretamente un’organizzazionePer dare la misura del problema vale la pena descrivere due scenari, scelti perché toccano direttamente situazioni che ogni dirigente IT può riconoscere nella propria organizzazione.Il primo scenario è l’esfiltrazione di dati riservati, ed è esattamente quello che EchoLeak ha portato alla luce. Un assistente AI che ha accesso a documenti aziendali, anche solo in lettura, può essere indotto a inviare il contenuto di quei documenti verso destinatari esterni. In ambito sanitario significa cartelle cliniche, in ambito finanziario significa posizioni di clienti, in ambito pubblico significa pratiche di cittadini. Il dato non viene rubato forzando un sistema ma viene consegnato dall’AI stessa nel tentativo di essere utile.Il secondo scenario è la manipolazione delle risposte. Un assistente AI che fornisce supporto ai decisori, riassumendo report o sintetizzando comunicazioni, può essere indotto a presentare informazioni sistematicamente distorte. Nei test condotti, una singola comunicazione avvelenata è stata sufficiente a forzare l’assistente a rispondere sempre in una determinata direzione, indipendentemente dalla domanda reale dell’utente. Le implicazioni in contesti dove l’AI supporta scelte di business, decisioni cliniche o valutazioni di rischio sono evidenti.Perché le difese tradizionali non bastano contro EchoLeakLa risposta istintiva di molte organizzazioni di fronte a queste minacce è chiedersi se l’antivirus, il firewall, i sistemi di rilevamento degli endpoint o le piattaforme di email security non risolvano il problema. La risposta onesta è che non lo risolvono, e per una ragione strutturale che vale la pena fissare con chiarezza. Gli strumenti di sicurezza tradizionali sono costruiti per riconoscere codice malevolo, allegati pericolosi, traffico anomalo, pattern noti. L’Indirect Prompt Injection non è nulla di tutto questo in quanto testo apparentemente innocuo, in linguaggio naturale, all’interno di documenti che dal punto di vista tecnico sono perfettamente legittimi. Non c’è una firma da rilevare, non c’è un eseguibile da analizzare, non c’è un comportamento sospetto in rete. L’attacco vive interamente all’interno del flusso di lavoro autorizzato dell’AI.Nemmeno i filtri costruiti dentro i modelli stessi offrono protezione sufficiente. I produttori di AI investono molto nell’addestramento difensivo, e Microsoft per esempio aveva implementato un classificatore specifico contro gli attacchi di prompt injection, ma EchoLeak è riuscita ad aggirarlo. Per ragioni matematiche è impossibile anticipare tutte le formulazioni possibili di un attacco linguistico, e gli aggressori sono sempre un passo avanti rispetto alla generazione successiva di filtri. Aggiungere un secondo modello AI che controlli il primo aiuta ma non risolve, perché entrambi soffrono della stessa natura probabilistica e possono essere ingannati con tecniche analoghe.Va detto che il quadro regolatorio europeo si sta muovendo nella direzione giusta. L’AI Act classifica diversi usi dell’AI come ad alto rischio e impone obblighi di valutazione e mitigazione, e la direttiva NIS2 richiede alle aziende dei settori essenziali di adottare misure di gestione del rischio adeguate, esplicitamente comprensive dei rischi della catena di fornitura digitale. Anche il Cyber Resilience Act spingerà i produttori a integrare sicurezza per design nei prodotti che includono componenti AI. Ma queste norme stabiliscono il dovere di proteggersi, non spiegano come farlo, e nessuna delle misure attualmente previste affronta in modo specifico il vettore della prompt injection indiretta, che è una vulnerabilità così nuova da non avere ancora un vocabolario condiviso nelle linee guida operative.Cosa può fare oggi un’organizzazioneNon esiste una soluzione tecnica unica che annulli il problema, ma esistono scelte di governance che riducono in modo significativo l’esposizione.La prima e più importante è rivedere il principio dei permessi concessi agli assistenti AI. La domanda da porsi per ogni capacità data al sistema è quale danno massimo possa produrre nel caso peggiore. Un assistente che legge le email per riassumerle non deve avere il permesso di inviarle, perché la lettura non implica la scrittura, e concedere entrambe per pura comodità apre uno scenario di esfiltrazione che diventa quasi automatico nel momento in cui un’email avvelenata arriva nella casella di un dirigente. Lo stesso vale per ogni altro accesso: l’AI deve avere il minimo indispensabile per fare il suo lavoro, e nulla di più.La seconda scelta riguarda la validazione umana per le azioni irreversibili. Nessun assistente AI dovrebbe poter inviare comunicazioni a clienti, modificare record, autorizzare pagamenti o trasferire dati verso l’esterno senza che un essere umano confermi esplicitamente l’azione. Vale la pena ricordare che chi sta vendendo automazione spinta in questi mesi prometterà di togliere proprio queste frizioni in nome della produttività. Toglierle equivale a disattivare i freni della propria auto perché frenare rallenta il viaggio.La terza scelta è considerare ogni contenuto esterno come potenzialmente ostile, anche se proviene da fonti interne all’organizzazione. Le email interne, i documenti caricati nelle basi di conoscenza, le note nei sistemi di ticketing sono tutte fonti che un attaccante può alimentare attraverso vettori indiretti, magari compromettendo un singolo account o sfruttando un fornitore della filiera. Il vecchio principio per cui dietro il perimetro aziendale ci si poteva fidare è stato superato dalla zero trust da molti anni nelle reti, e va ora applicato anche ai contenuti che alimentano l’AI.La quarta scelta, più difficile da formalizzare ma probabilmente la più importante, è la consapevolezza diffusa nei reparti che non si occupano direttamente di sicurezza. I dirigenti che approvano l’adozione di assistenti AI, i responsabili dei processi che li integrano nei flussi di lavoro, gli amministratori che configurano i permessi devono sapere che ogni nuova integrazione apre una superficie di rischio specifica. La velocità con cui questi sistemi vengono adottati oggi, spesso senza un coinvolgimento adeguato delle funzioni di sicurezza, è il fattore che più di ogni altro spiegherà gli incidenti di domani.ConclusioniIl punto da cui partire, e che vale la pena fissare al di là dei dettagli tecnici, è che l’AI cambia la natura stessa di cosa significa proteggere un sistema. Per decenni la cybersecurity ha lavorato sull’idea che il software facesse esattamente ciò per cui era stato programmato, e che il compito del difensore fosse impedire a estranei di alterarlo. Con i sistemi basati su modelli linguistici questo non vale più. Il software risponde alle istruzioni che riceve, e nel momento in cui legge un documento, quel documento può contenere istruzioni che il software seguirà come se fossero state impartite dal proprio amministratore. La superficie di attacco non è più solo nei canali di rete o nelle credenziali, è in ogni email, in ogni PDF, in ogni nota interna che l’AI elaborerà.Per chi guida un’organizzazione la conseguenza è che l’adozione dell’AI non può più essere trattata come l’introduzione di uno strumento di produttività in più, da valutare sul ritorno di efficienza atteso. È una scelta architetturale che ridefinisce il perimetro di sicurezza dell’azienda, e che richiede di essere governata con la stessa serietà con cui si gestiscono migrazioni in cloud o cambi di sistema gestionale. Le organizzazioni che lo capiranno per tempo costruiranno un vantaggio competitivo solido, perché potranno sfruttare l’AI in pieno avendo strutturato attorno a essa le difese adeguate. Quelle che continueranno a trattarla come una funzione da accendere e dimenticare scopriranno, in tempi che misureremo in mesi e non in anni, che il proprio assistente ha imparato ad ascoltare anche persone che nessuno aveva mai autorizzato a parlargli.