Per quattro settimane a partire dal 21 gennaio, il Copilot di Microsoft ha letto e digerito e-mail riservate nonostante tutte le etichette di riservatezza e la politica DLP gli dicessero di non farlo. I punti di implementazione erano interrotti nella linea di Microsoft e nessuno strumento di sicurezza nello stack lo ha segnalato. Tra le organizzazioni colpite c’era il Servizio sanitario nazionale del Regno Unito. Salvato come INC46740412 – Un segnale di quanto il fallimento abbia raggiunto gli ambienti sanitari regolamentati. Microsoft lo ha tracciato come CW1226324.
Consiglio, segnalato per la prima volta da BleepingComputer Questo incidente, avvenuto il 18 febbraio, segna la seconda volta in otto mesi che la pipeline di acquisizione dati di Copilot ha violato il suo confine di fiducia; si tratta del mancato accesso o trasmissione da parte di un sistema di intelligenza artificiale di dati che gli è espressamente vietato toccare. Il primo era peggio.
Microsoft ha applicato la patch nel giugno 2025 CVE-2025-32711Una vulnerabilità critica a zero clic che i ricercatori di Aim Security chiamano “EchoLeak”. Un’e-mail dannosa ha aggirato il classificatore di iniezione rapida, l’orchestrazione dei collegamenti, la policy di sicurezza dei contenuti e le espressioni di riferimento di Copilot per esfiltrare silenziosamente i dati aziendali. Non sono stati richiesti clic né azioni da parte dell’utente. Microsoft gli ha assegnato un Punteggio CVSS 9.3.
Due diverse cause profonde; un unico punto cieco: un errore di codice e una complessa catena di exploit hanno prodotto lo stesso risultato. Al copilota era chiaramente vietato toccare i dati che stava elaborando e lo stack di sicurezza non ha visto nulla.
Perché EDR e WAF continuano a essere architetturalmente ciechi rispetto a questo problema?
Il rilevamento e la risposta degli endpoint (EDR) monitora il comportamento di file e processi. I firewall delle applicazioni Web (WAF) ispezionano i payload HTTP. Non esiste una categoria di rilevamento come “Il tuo assistente di intelligenza artificiale ha violato il proprio limite di fiducia”. Questo divario esiste perché le pipeline di recupero LLM risiedono dietro un livello applicativo che gli strumenti di sicurezza tradizionali non sono mai stati progettati per osservare.
Il copilota ha ricevuto un’e-mail etichettata che gli è stato detto di ignorare e tutta l’azione si è svolta all’interno dell’infrastruttura Microsoft. Tra indice di recupero e modello di generazione. Niente ha colpito il disco, nessun traffico anomalo ha attraversato il perimetro e non è emerso alcun processo da segnalare all’agente endpoint. Lo stack di sicurezza ha riferito che tutto andava bene perché non ha mai visto il livello in cui si è verificata la violazione.
Secondo il consiglio di Microsoft, il bug CW1226324 ha funzionato perché un errore nel percorso del codice consentiva ai messaggi in Posta inviata e Bozze di entrare nel set di ricezione di Copilot nonostante i tag di riservatezza e le regole DLP che avrebbero dovuto bloccarli. EchoLeak ha funzionato perché i ricercatori di Aim Security hanno dimostrato che un’e-mail dannosa formulata in modo da sembrare una normale corrispondenza aziendale potrebbe manipolare la pipeline di accesso potenziato di Copilot per accedere ai dati interni e inoltrarli a un server controllato dagli aggressori.
I ricercatori di Aim Security lo descrivono in questo modo: difetto di progettazione fondamentale: Gli intermediari elaborano dati attendibili e non attendibili attraverso lo stesso processo di pensiero, rendendoli intrinsecamente vulnerabili alla manipolazione. Questo difetto di progettazione non è scomparso quando Microsoft ha patchato EchoLeak. CW1226324 dimostra che il livello applicativo attorno ad esso può fallire in modo indipendente.
Ispezione in cinque punti corrispondente a entrambe le modalità di guasto
Nessuno dei due guasti ha attivato un singolo avviso. Entrambi sono stati scoperti tramite canali di riferimento dei fornitori, non tramite SIEM, EDR o WAF.
CW1226324 è stato reso disponibile al pubblico il 18 febbraio. Gli inquilini interessati erano stati denunciati dal 21 gennaio. Microsoft non ha rivelato quante organizzazioni sono state interessate o a quali dati è stato effettuato l’accesso durante questo periodo. Questo divario è la storia dei leader della sicurezza: un’esposizione di quattro settimane nella pipeline di inferenza di un fornitore, invisibile a ogni strumento nello stack e scoperta solo perché Microsoft ha scelto di pubblicare un advisory.
1. Testare l’implementazione DLP direttamente su Copilot. CW1226324 esiste da quattro settimane perché nessuno ha verificato se Copilot seguisse effettivamente le etichette di riservatezza nella posta inviata e nelle bozze. Crea messaggi di prova contrassegnati in cartelle controllate, interroga Copilot e verifica che non possano emergere. Fai questo test mensilmente. La configurazione non è un’applicazione; l’unica prova è un tentativo di recupero fallito.
2. Impedire che il contenuto esterno raggiunga la finestra del contenuto di Copilot. EchoLeak ha avuto successo perché un’e-mail dannosa è entrata nel set di accesso di Copilot e le istruzioni inserite sono state eseguite come se fossero la query dell’utente. Secondo la dichiarazione di Aim Security, l’attacco ha aggirato quattro diversi livelli di difesa: il classificatore di cross-request injection di Microsoft, l’orchestrazione dei collegamenti esterni, i controlli della Content-Security-Policy e le protezioni dei riferimenti. Disabilita il contenuto e-mail esterno nelle impostazioni di Copilot e limita il rendering Markdown sugli output AI. Ciò cattura la classe di fallimento dell’iniezione rapida rimuovendo completamente la superficie di attacco.
3. Controllare i registri di Purview per eventuali interazioni anomale del Copilot durante la finestra di esposizione da gennaio a febbraio. Cerca le query di Copilot Chat che restituiscono contenuti dai messaggi contrassegnati tra il 21 gennaio e la metà di febbraio 2026. Nessuna delle due classi di errore ha prodotto avvisi tramite l’EDR o il WAF disponibili; quindi il rilevamento retroattivo dipende dalla telemetria Purview. Se il tuo tenant non è in grado di ricreare ciò a cui ha avuto accesso Copilot durante il periodo di esposizione, documenta formalmente questa lacuna. È importante per l’armonia. Per qualsiasi organizzazione soggetta a revisione normativa, una vulnerabilità di accesso ai dati AI non documentata durante una finestra di vulnerabilità nota è un risultato di audit in attesa di verificarsi.
4. Attiva Individuazione contenuto limitato per siti di SharePoint con dati sensibili. RCD rimuove completamente i siti dalla linea di accesso di Copilot. Funziona indipendentemente dal fatto che la violazione della fiducia sia dovuta a un errore di codice o a un prompt inserito, poiché i dati non entrano mai nella finestra di contesto. Questo è lo strato di contenimento che non è attaccato al punto di applicazione interrotto. Per le organizzazioni che trattano dati sensibili o regolamentatiIl RCD non è facoltativo.
5. Creare un playbook di risposta agli incidenti per gli errori di inferenza ospitati dal fornitore. I playbook di risposta agli incidenti (IR) necessitano di una nuova categoria: violazioni dei limiti di attendibilità nella pipeline di inferenza del fornitore. Identificare i modi per migliorare. Assegna la proprietà. Stabilire una cadenza di monitoraggio per i consigli sullo stato dei servizi del fornitore che influiscono sull’elaborazione dell’intelligenza artificiale. Il tuo SIEM non sarà in grado di catturare neanche quello successivo.
Modello che va oltre Copilot
UN. Sondaggio 2026 degli addetti ai lavori sulla sicurezza informatica È emerso che il 47% dei CISO e dei leader senior della sicurezza hanno attualmente osservato agenti di intelligenza artificiale esibire comportamenti indesiderabili o non autorizzati. Le organizzazioni stanno implementando gli assistenti IA nella produzione più velocemente di quanto riescano a costruire una governance attorno ad essi.
Questa traiettoria è importante perché questo framework non è esclusivo di Copilot. Qualsiasi assistente basato su RAG che sfrutta i dati aziendali passa attraverso lo stesso modello: un livello di acquisizione seleziona il contenuto, un livello di applicazione controlla ciò che il modello può vedere e un livello di produzione produce output. Se il livello dell’applicazione fallisce, il livello di acquisizione inserisce i dati riservati nel modello e lo stack di sicurezza non li vede mai. Copilot, Gemini for Workspace e qualsiasi strumento che accede ai documenti interni presentano lo stesso rischio intrinseco.
Conduci l’audit in cinque punti prima della prossima riunione del consiglio. Inizia con messaggi di prova etichettati in una cartella controllata. Se Copilot li rivela, ogni politica sottostante è teatro.
Risposta del consiglio: “Le nostre policy sono configurate correttamente. L’applicazione non è riuscita sulla pipeline di inferenza del fornitore. Ecco cinque controlli che testiamo, limitiamo e richiediamo prima di riattivare l’accesso completo per carichi di lavoro sensibili.”
Al successivo malfunzionamento non verrà inviato alcun avviso.
