Per quattro settimane a partire dal 21 gennaio, il Copilota di Microsoft ha letto e riepilogato le e-mail riservate nonostante ogni etichetta di riservatezza e politica DLP gli dicesse di non farlo. I punti di applicazione si sono verificati all’interno della pipeline di Microsoft e nessuno strumento di sicurezza nello stack l’ha segnalato. Tra le organizzazioni colpite c’period il Servizio Sanitario Nazionale del Regno Unito, che lo ha registrato come INC46740412 – un segnale di quanto il fallimento sia arrivato negli ambienti sanitari regolamentati. Microsoft lo ha rintracciato come CW1226324.
La consulenza, segnalato per la prima volta da BleepingComputer il 18 febbraio, segna la seconda volta in otto mesi che la pipeline di recupero di Copilot ha violato il proprio confine di fiducia: un errore in cui un sistema di intelligenza artificiale accede o trasmette dati a cui period stato esplicitamente impedito di toccare. Il primo period peggio.
Nel giugno 2025, Microsoft ha applicato la patch CVE-2025-32711una vulnerabilità critica a zero clic che i ricercatori di Goal Safety hanno soprannominato “EchoLeak”. Un’e-mail dannosa ha aggirato il classificatore di immediate injection di Copilot, la redazione dei collegamenti, la coverage di sicurezza dei contenuti e i riferimenti ai riferimenti per esfiltrare silenziosamente i dati aziendali. Non sono stati richiesti clic né alcuna azione da parte dell’utente. Microsoft gli ha assegnato un Punteggio CVSS di 9,3.
Due numerous trigger profonde; un punto cieco: un errore di codice e una sofisticata catena di exploit hanno prodotto un risultato identico. Il copilota ha elaborato i dati che period esplicitamente vietato toccare e lo stack di sicurezza non ha visto nulla.
Perché EDR e WAF continuano a essere architetturalmente ciechi riguardo a questo
Il rilevamento e la risposta degli endpoint (EDR) monitora il comportamento di file e processi. I firewall delle applicazioni Net (WAF) ispezionano i payload HTTP. Né esiste una categoria di rilevamento per “il tuo assistente AI ha appena violato il proprio confine di fiducia”. Questo divario esiste perché le pipeline di recupero LLM si trovano dietro un livello di applicazione che gli strumenti di sicurezza tradizionali non sono mai stati progettati per osservare.
Copilot ha importato un’e-mail etichettata che gli period stato detto di ignorare e l’intera azione è avvenuta all’interno dell’infrastruttura Microsoft. Tra l’indice di recupero e il modello di generazione. Niente è stato trasferito sul disco, nessun traffico anomalo ha attraversato il perimetro e nessun processo è stato generato per essere contrassegnato da un agente endpoint. Lo stack di sicurezza ha segnalato il through libera perché non ha mai visto il livello in cui si è verificata la violazione.
Il bug CW1226324 ha funzionato perché un errore nel percorso del codice consentiva ai messaggi nella posta inviata e nelle bozze di entrare nel set di recupero di Copilot nonostante le etichette di riservatezza e le regole DLP che avrebbero dovuto bloccarli, secondo l’avviso di Microsoft. EchoLeak ha funzionato perché i ricercatori di Goal Safety hanno dimostrato che un’e-mail dannosa, formulata in modo da sembrare una normale corrispondenza aziendale, poteva manipolare la pipeline di generazione aumentata di recupero di Copilot per accedere e trasmettere dati interni a un server controllato dall’aggressore.
I ricercatori di Goal Safety lo hanno caratterizzato come a difetto di progettazione fondamentale: gli agenti elaborano dati attendibili e non attendibili nello stesso processo di pensiero, rendendoli strutturalmente vulnerabili alla manipolazione. Quel difetto di progettazione non è scomparso quando Microsoft ha patchato EchoLeak. CW1226324 dimostra che il livello di applicazione attorno advert esso può fallire in modo indipendente.
L’audit in cinque punti che mappa entrambe le modalità di guasto
Nessuno dei due guasti ha attivato un singolo avviso. Entrambi sono stati scoperti tramite canali di consulenza dei fornitori, non tramite SIEM, non tramite EDR, non tramite WAF.
CW1226324 è stato reso 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 quel periodo. Per i chief della sicurezza, questa lacuna è la storia: un’esposizione di quattro settimane all’interno della pipeline di inferenza di un fornitore, invisibile a ogni strumento nello stack, scoperta solo perché Microsoft ha scelto di pubblicare un advisory.
1. Testare l’applicazione DLP direttamente su Copilot. CW1226324 esisteva da quattro settimane perché nessuno ha verificato se Copilot rispettasse effettivamente le etichette di riservatezza sugli elementi inviati e sulle bozze. Crea messaggi di prova etichettati in cartelle controllate, interroga Copilot e conferma che non può visualizzarli. Esegui questo take a look at mensilmente. La configurazione non è un’applicazione; l’unica prova è un tentativo di recupero fallito.
2. Impedisci al contenuto esterno di raggiungere la finestra di contesto di Copilot. EchoLeak ha avuto successo perché un’e-mail dannosa è entrata nel set di recupero di Copilot e le istruzioni inserite sono state eseguite come se fossero la question dell’utente. Secondo la divulgazione di Goal Safety, l’attacco ha aggirato quattro distinti livelli di difesa: il classificatore di cross-prompt injection di Microsoft, la redazione dei collegamenti esterni, i controlli della Content material-Safety-Coverage e le misure di salvaguardia delle menzioni di riferimento. Disabilita il contesto e-mail esterno nelle impostazioni di Copilot e limita il rendering Markdown negli output AI. Questo rileva la classe di fallimento della pronta iniezione rimuovendo completamente la superficie di attacco.
3. Controllare i registri di competenza per interazioni anomale del copilota durante la finestra di esposizione da gennaio a febbraio. Cerca le question di Copilot Chat che hanno restituito contenuto da messaggi etichettati tra il 21 gennaio e metà febbraio 2026. Nessuna delle classi di errore ha prodotto avvisi tramite EDR o WAF esistente, quindi il rilevamento retrospettivo dipende dalla telemetria di Purview. Se il tuo tenant non riesce a ricostruire ciò a cui ha avuto accesso Copilot durante la finestra di esposizione, documenta formalmente story lacuna. È importante per la conformità. Per qualsiasi organizzazione soggetta advert esame normativo, un divario di accesso ai dati AI non documentato 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 pipeline di recupero di Copilot. Funziona indipendentemente dal fatto che la violazione della fiducia provenga da un bug del codice o da un immediate inserito, perché i dati non entrano mai nella finestra di contesto. Questo è lo strato di contenimento che non dipende dal punto di applicazione che si è rotto. Per le organizzazioni che gestiscono dati sensibili o regolamentatiil DMC non è facoltativo.
5. Costruisci 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à all’interno della pipeline di inferenza del fornitore. Definire i percorsi di escalation. Assegna la proprietà. Stabilire una cadenza di monitoraggio per gli avvisi sullo stato dei servizi del fornitore che influiscono sull’elaborazione dell’intelligenza artificiale. Il tuo SIEM non catturerà neanche quello successivo.
Il modello che si trasferisce oltre Copilot
UN Sondaggio 2026 condotto da Cybersecurity Insiders ha scoperto che il 47% dei CISO e dei chief senior della sicurezza hanno già osservato che gli agenti di intelligenza artificiale esibiscono comportamenti non intenzionali o non autorizzati. Le organizzazioni stanno implementando gli assistenti IA nella produzione più velocemente di quanto riescano a costruire una governance attorno advert essi.
Questa traiettoria è importante perché questo framework non è specifico di Copilot. Qualsiasi assistente basato su RAG che estrae dati aziendali segue lo stesso schema: un livello di recupero seleziona il contenuto, un livello di applicazione controlla ciò che il modello può vedere e un livello di generazione produce output. Se il livello di applicazione fallisce, il livello di recupero fornisce dati riservati al modello e lo stack di sicurezza non li vede mai. Copilot, Gemini for Workspace e qualsiasi strumento con accesso al recupero di documenti interni comportano lo stesso rischio strutturale.
Esegui l’audit in cinque punti prima della prossima riunione del consiglio. Inizia con messaggi di prova etichettati in una cartella controllata. Se Copilot li fa emergere, ogni politica sottostante è teatro.
Il consiglio risponde: “Le nostre coverage sono state configurate correttamente. L’applicazione non è riuscita all’interno della pipeline di inferenza del fornitore. Ecco i cinque controlli che stiamo testando, limitando e richiedendo prima di riattivare l’accesso completo per i carichi di lavoro sensibili.”
Il prossimo errore non invierà un avviso.
