Copilot Chat sammanfattade konfidentiell e-post i veckor på grund av en kodbugg

Microsoft 365 Copilot Chat läste och sammanfattade e-postmeddelanden som dess egen konfiguration skulle hålla borta från den. Microsofts tjänstmeddelande, som spåras i administratörens meddelandecenter som CW1226324, daterar den första identifieringen till 21 januari 2026, och åtgärden rullades fortfarande ut fyra veckor senare. Det påverkade chatten på "arbetsfliken" i Microsoft 365 Copilot Chat, som hämtade meddelanden från användarnas mappar Skickat och Utkast och sammanfattade dem även när dessa meddelanden hade en känslighetsetikett för Konfidentiellt och en princip för dataförlustskydd hade konfigurerats för att stoppa just detta. BleepingComputer rapporterade om meddelandet den 18 februari 2026, det datum som arkivet tilldelar posten; Microsoft har inte angett hur många organisationer som påverkades. Den fullständiga posten, med sin allvarlighetsgrad och konfidensbedömning, finns i Orca AI Incident Archive, tillsammans med de andra posterna i den här serien.

Copilot Chat är Microsofts innehållsmedvetna assistent som låter användare ställa frågor till AI-agenter inifrån Word, Excel, PowerPoint, Outlook och OneNote. Enligt BleepingComputer började Microsoft rulla ut den till betalande företagskunder med Microsoft 365 i september 2025. Det innebär att den drabbade gruppen är de företagsklientorganisationer som hade köpt produkten och sedan tillämpat de styrningskontroller som produkten såldes tillsammans med.

Vad servicevarningen faktiskt sa

Det primära dokumentet här är inte en publicerad rådgivning eller en CVE-post. Det är ett meddelande i Microsoft 365-administrationscentret, synligt för tenant-administratörer, som BleepingComputer säger sig ha sett och citerat. Microsofts formulering, såsom mediet återgav den, är specifik om mekanismen:

Användarnas e-postmeddelanden med en tillämpad konfidentiell etikett bearbetas felaktigt av Microsoft 365 Copilot-chatt.

Chatten i {{1}}Microsoft 365 Copilot 'work tab'{{/1}} sammanfattar e-postmeddelanden trots att dessa e-postmeddelanden har en känslighetsetikett tillämpad och en DLP-princip är konfigurerad.

Ett kodproblem gör att objekt i mapparna Skickat och Utkast kan fångas upp av Copilot även om konfidentiella etiketter är inställda.

BleepingComputer noterade att Microsoft klassade posten som en rådgivning snarare än en incident – en flagga som mediet beskriver som vanligt använd för tjänsteproblem med begränsad omfattning eller påverkan. Ingen CVE-identifierare förekommer i Microsofts varning eller i någon av den rapportering som granskats för den här artikeln. Detta är en defekt på serversidan i en värdbaserad tjänst, inte en produktbrist med en patchbulletin, vilket är anledningen till att posten finns i en tjänstehälsokonsol snarare än i Microsofts säkerhetsresponscenter.

Tidslinjen som Microsoft publicerade, och den del som lämnades öppen

Varningens datum är det mest tillförlitliga i underlaget, och de är Microsofts egna.

Fyra veckor skiljer den första upptäckten från den första offentliga rapporten. Microsofts egen redogörelse anger inte hur länge defekten hade varit aktiv före den 21 januari, och den anger inte något datum då varje klientorganisation hade fått åtgärden. Uppdateringen den 20 februari säger att utrullningen fortfarande pågick för vad den kallar "en liten del av våra mer komplexa tjänstemiljöer" – vilket är ett uttalande om att vissa kunder fortfarande var exponerade vid den tidpunkten, utan att säga vilka eller hur många.

Fyra kontroller, och den som gav vika

Anledningen till att detta är ett styrningsmisslyckande snarare än en enkel felaktig utlösning är att alla kontroller fanns på plats och bara den sista brast. Känslighetsetiketter, DLP-principer och åtkomstkontroller för klientorganisationen är tre separata mekanismer, och Copilots egen hämtningsväg är en fjärde. Varningen säger att de två första var konfigurerade. Microsoft säger att den tredje höll. Den fjärde gjorde det inte.

Den distinktionen spelar roll för alla som läser incidenten som en dataintrång. En känslighetsetikett är en avsiktsförklaring som är kopplad till ett meddelande; den stoppar inte något i sig själv. Något måste läsa den och vägra. I ett normalt Microsoft 365-klientutrymme är det något DLP-motorn för delning och Copilot-hämtningslagret för AI-bearbetning. Enligt varningen fanns både etiketten och DLP-regeln på plats, och meddelandena sammanfattades ändå, eftersom kodvägen som skulle ha rådgjort med dem inte gjorde det.

Vad Microsoft säger exponerades, och vad det inte säger

Microsofts sakliga kommentar kom den 19 februari, en dag efter artikeln, i ett uttalande till BleepingComputer som företaget upprepade för BBC och för IT Pro:

Vi identifierade och åtgärdade ett problem där Microsoft 365 Copilot Chat kunde returnera innehåll från e-postmeddelanden märkta som konfidentiella, skapade av en användare och lagrade i deras Utkast och Skickade objekt i Outlook för skrivbordet. Detta gav inte någon åtkomst till information som de inte redan var behöriga att se.

Även om våra åtkomstkontroller och dataskyddspolicyer förblev intakta uppfyllde detta beteende inte vår avsedda Copilot-upplevelse, som är utformad för att utesluta skyddat innehåll från Copilot-åtkomst. En konfigurationsuppdatering har distribuerats globalt för företagskunder.

Två fraser i det uttalandet gör mycket för att begränsa omfattningen, och båda är Microsofts, inte en oberoende slutsats. Den första är "skrivet av en användare": de berörda meddelandena är sådana som användaren själv har skrivit och sparat i sina egna Skickat eller Utkast, inte e-post från andra personers postlådor. Den andra är "Outlook desktop", vilket begränsar felet till en klient i stället för till Copilot Chat överallt. Läst tillsammans beskriver Microsoft en defekt där personer visades sammanfattningar av sin egen skyddade korrespondens – inte en defekt där en användare läste en annans.

Det är förenligt med arkivregistreringen att det rör sig om verklig skada och hög allvarlighetsgrad, eftersom skadan i protokollet inte är utlämnande till en tredje part. Det är att innehåll som en organisation uttryckligen hade klassificerat och avskärmat ändå intogs och behandlades av ett AI-system, från den första upptäckten den 21 januari till dess att åtgärden nådde den tenanten. Microsofts egen mening medger den garanti som brast: produkten "är utformad för att utesluta skyddat innehåll från Copilot-åtkomst", och det gjorde den inte.

Vad Microsoft inte har sagt, i något uttalande som granskats för den här artikeln: hur många tenants som påverkades, om det bearbetade innehållet behölls någonstans utöver sammanfattningen, om det var synligt i granskningsloggar i en form som kunderna kunde återskapa, och om något av det nådde en pipeline för modellträning. Företaget sade till BleepingComputer att omfattningen av påverkan "kan ändras i takt med att utredningen fortskrider" och har inte publicerat någon siffra sedan dess.

Vilka påverkades, och hur långt bevisningen sträcker sig

Ingen kundlista har publicerats. Den enda namngivna organisationen i rapporteringen är National Health Service i England: BBC rapporterade den 19 februari att Microsofts meddelande hade delats på en dashboard för NHS IT-support, och att ett avsnitt i meddelandet på den webbplatsen antyder att NHS påverkades. Samma BBC-rapport säger också att den fick veta att innehållet i eventuella utkast eller skickade e-postmeddelanden som behandlats av Copilot Chat skulle finnas kvar hos dem som skapat dem, och att patientinformation inte hade exponerats. VentureBeat rapporterar i en senare analys att NHS loggade problemet internt som INC46740412.

NHS:s supportsida som dessa medier hänvisar till omdirigerar nu till startsidan för supporthub.nhs.net, så själva meddelandet kunde inte läsas för den här artikeln; BBC:s beskrivning av det är den tillgängliga bevisningen, och den är andrahandsuppgift. Arkivet klassificerar regionen som global, vilket stämmer överens med en konfigurationsuppdatering som Microsoft uppger sig ha rullat ut globalt, men ingen jurisdiktion har publicerat en lista över drabbade klientorganisationer.

Oberoende bekräftelse av kärnfakta är i övrigt solid. BBC:s teknikreporter Liv McMahon bekräftade mekanismen och Microsofts uttalande den 19 februari; IT Pro:s Nicole Kobie bekräftade detekteringsdatumet den 21 januari och spårnings-ID:t samma dag; TechCrunch rapporterade den 18 februari att Microsoft inte ville säga hur många kunder som påverkades. Ingen av dessa medier ifrågasätter sekvensen. Ingen av dem har oberoende verifierat vad Copilot gjorde med innehållet.

Vad förändrades, och vad förändrades inte

Microsofts åtgärd var en riktad kodrättning plus en konfigurationsändring. Uppdateringen av varningen den 20 februari, som citeras av BleepingComputer, lyder:

Vår riktade kodåtgärd för att förhindra ytterligare påverkan fortskrider och har nu nått full täckning i majoriteten av de drabbade miljöerna. Vår utrullning pågår fortfarande endast för en liten del av våra mer komplexa tjänstemiljöer.

Därför anser vi att grundorsaken till det här problemet har åtgärdats för de flesta kunder, och inga nya e-postmeddelanden för kunder som har fått korrigeringen kommer att påverkas framöver.

Innan dess, den 18 februari, sade Microsoft att man övervakade utrullningen och kontaktade en delmängd av drabbade användare för att verifiera att åtgärden fungerade. Ingen slutlig tidsplan för åtgärdande angavs då, och ingen har publicerats sedan dess.

Det som inte ändrades är den kontrollarkitektur som möjliggjorde felet. Etiketten och DLP-regeln beskriver fortfarande avsikten; Copilots hämtningsväg upprätthåller den fortfarande. Microsofts uttalande att dess "åtkomstkontroller och dataskyddspolicyer förblev intakta" är korrekt så långt det sträcker sig – policyerna ändrades eller raderades inte – men det innebär också att policyerna aldrig var det som utförde blockeringen.

Vad protokollet fastställer, och vad det bara påstår

Tre nivåer av påståenden ryms i den här händelsen, och de är värda att hålla isär.

Fastställt: en koddefekt i fliken Copilot Chat för arbete gjorde att märkta, DLP-skyddade meddelanden i Sent Items och Drafts sammanfattades; Microsoft upptäckte den 21 januari 2026, spårade den som CW1226324, började åtgärda den i början av februari och uppgav den 20 februari att grundorsaken hade åtgärdats för de flesta kunder. Dessa fakta kommer från Microsofts egen tjänsteavisering och bekräftas av BBC, IT Pro och TechCrunch.

Påstått av Microsoft, inte oberoende verifierat: att ingen fick åtkomst till information som de inte redan var behöriga att se; att de berörda meddelandena hade skrivits av den drabbade användaren och var begränsade till Outlook för skrivbordet; och att åtkomstkontroller och dataskyddspolicyer förblev intakta under hela förloppet.

Inte fastställt av någon: antalet drabbade organisationer; volymen meddelanden som behandlats; vad som hände med innehållet efter sammanfattningen; och huruvida någon tillsynsmyndighet har inlett en utredning. Ingen av de rapporteringar som har granskats för den här artikeln namnger någon.

Nader Henein, analytiker inom dataskydd och AI-styrning på Gartner, sade till BBC att "den här typen av misstag är oundvikliga" med tanke på hur ofta nya AI-funktioner lanseras, och att organisationer normalt skulle stänga av en funktion och vänta på att styrningen hinner ikapp – men att pressen som AI-hypen skapar gör det nästan omöjligt. Professor Alan Woodward vid University of Surrey sade till samma medie att incidenten visar varför sådana verktyg bör vara privata som standard och endast aktiveras genom ett aktivt val. Båda är beskrivningar av mönstret snarare än slutsatser om just den här specifika defekten, och bör läsas som det.

Den snäva lärdomen som underlaget ger stöd för är mindre dramatisk än rubrikerna och mer användbar: kontrollen som misslyckades var den som kunden uttryckligen hade konfigurerat, och den misslyckades i ett lager som kunden inte kunde inspektera. Microsofts åtgärd stängde kodvägen. Den gav inte klientorganisationer något sätt att självständigt verifiera att vägen förblir stängd.