Copilot Chat Summarised Confidential Email for Weeks Because of a Code Bug

Microsoft 365 Copilot Chat read and summarised emails that its own configuration was supposed to keep away from it. Microsoft's service alert, tracked in the admin Message Center as CW1226324, dates first detection to 21 January 2026, and the fix was still rolling out four weeks later. It affected the "work tab" chat inside Microsoft 365 Copilot Chat, which pulled messages from users' Sent Items and Drafts folders and summarised them even where those messages carried a Confidential sensitivity label and a data loss prevention policy had been configured to stop exactly that. BleepingComputer reported the alert on 18 February 2026, the date the archive assigns the entry; Microsoft has not said how many organisations were affected. The full record, with its severity and confidence grading, sits in the Orca AI Incident Archive, alongside the other entries in this series.

Copilot Chat is Microsoft's content-aware assistant that lets users query AI agents from inside Word, Excel, PowerPoint, Outlook and OneNote. Microsoft began rolling it out to paying Microsoft 365 business customers in September 2025, according to BleepingComputer. That makes the affected population the enterprise tenants that had bought the product and then applied the governance controls the product was sold alongside.

What the service alert actually said

The primary document here is not a published advisory or a CVE record. It is a message in the Microsoft 365 admin center, visible to tenant administrators, which BleepingComputer says it saw and quoted. Microsoft's wording, as the outlet reproduced it, is specific about the mechanism:

"Users' email messages with a confidential label applied are being incorrectly processed by Microsoft 365 Copilot chat."

"The Microsoft 365 Copilot 'work tab' Chat is summarizing email messages even though these email messages have a sensitivity label applied and a DLP policy is configured."

"A code issue is allowing items in the sent items and draft folders to be picked up by Copilot even though confidential labels are set in place."

BleepingComputer noted that Microsoft tagged the item as an advisory rather than an incident — a flag the outlet describes as commonly used for service issues with limited scope or impact. No CVE identifier appears in Microsoft's alert or in any of the coverage reviewed for this article. This is a server-side defect in a hosted service, not a product flaw with a patch bulletin, which is why the record lives in a service-health console rather than in Microsoft's security response centre.

The timeline Microsoft published, and the part it left open

The alert's dates are the firmest thing in the record, and they are Microsoft's own.

Four weeks separate first detection from the first public report. Microsoft's own account does not say how long the defect had been live before 21 January, and it does not give a date on which every tenant received the fix. The 20 February update says deployment was still in progress for what it calls "a small section of our more complex service environments" — which is a statement that some customers were still exposed at that point, without saying which or how many.

Four controls, and the one that gave way

The reason this is a governance failure rather than a simple misfire is that the controls were all in place and only the last one broke. Sensitivity labels, DLP policies and tenant access controls are three separate mechanisms, and Copilot's own retrieval path is a fourth. The alert says the first two were configured. Microsoft says the third held. The fourth did not.

That distinction matters for anyone reading the incident as a data breach. A sensitivity label is a statement of intent attached to a message; it does not itself stop anything. Something has to read it and refuse. In the normal course of a Microsoft 365 tenant, that something is the DLP engine for sharing and the Copilot retrieval layer for AI processing. According to the alert, both the label and the DLP rule were present, and the messages were summarised anyway, because the code path that was supposed to consult them did not.

What Microsoft says was exposed, and what it does not say

Microsoft's substantive comment came on 19 February, a day after the article, in a statement to BleepingComputer that the company repeated to the BBC and to IT Pro:

"We identified and addressed an issue where Microsoft 365 Copilot Chat could return content from emails labeled confidential authored by a user and stored within their Draft and Sent Items in Outlook desktop. This did not provide anyone access to information they weren't already authorized to see."

"While our access controls and data protection policies remained intact, this behavior did not meet our intended Copilot experience, which is designed to exclude protected content from Copilot access. A configuration update has been deployed worldwide for enterprise customers."

Two phrases in that statement do a lot of narrowing work, and both are Microsoft's, not an independent finding. The first is "authored by a user": the affected messages are ones the user wrote themselves and kept in their own Sent Items or Drafts, not mail from other people's mailboxes. The second is "Outlook desktop", which scopes the fault to one client rather than to Copilot Chat everywhere. Read together, Microsoft is describing a defect in which people were shown summaries of their own protected correspondence — not a defect in which one user read another's.

That is compatible with the archive recording real harm and a high severity, because the harm in the record is not disclosure to a third party. It is that content an organisation had explicitly classified and fenced off was ingested and processed by an AI system anyway, from first detection on 21 January until the fix reached that tenant. Microsoft's own sentence concedes the guarantee that broke: the product "is designed to exclude protected content from Copilot access," and it did not.

What Microsoft has not said, in any statement reviewed for this article: how many tenants were affected, whether the processed content was retained anywhere beyond the summary, whether it was visible in audit logs in a form customers could reconstruct, and whether any of it reached a model-training pipeline. The company told BleepingComputer that the scope of impact "may change as the investigation continues" and has published no figure since.

Who was affected, and how far the evidence reaches

No customer list has been published. The one named organisation in the reporting is the National Health Service in England: the BBC reported on 19 February that Microsoft's notice had been shared on an NHS IT support dashboard, and that a section of the notice on that site implies the NHS was affected. The same BBC report also says it was told that the contents of any draft or sent email processed by Copilot Chat would remain with their creators, and that patient information had not been exposed. VentureBeat, in a later analysis, reports that the NHS logged the issue internally as INC46740412.

The NHS support page those outlets cite now redirects to the supporthub.nhs.net front page, so the notice itself could not be read for this article; the BBC's characterisation of it is the available evidence, and it is second-hand. The archive classifies the region as global, which is consistent with a configuration update Microsoft says it deployed worldwide, but no jurisdiction has published a list of affected tenants.

Independent corroboration of the core facts is otherwise solid. The BBC's technology reporter Liv McMahon confirmed the mechanism and Microsoft's statement on 19 February; IT Pro's Nicole Kobie confirmed the 21 January detection date and the tracking ID the same day; TechCrunch reported on 18 February that Microsoft would not say how many customers were affected. None of those outlets disputes the sequence. None of them has independently verified what Copilot did with the content.

What changed, and what did not

Microsoft's remediation was a targeted code fix plus a configuration change. The 20 February alert update, quoted by BleepingComputer, reads:

"Our targeted code fix to prevent further impact is moving forward and has saturated across the majority of affected environments. Our deployment remains in progress only for a small section of our more complex service environments."

"As such, we believe the root cause of this issue has been addressed for most customers, and no new email messages for customers who have received the fix will be affected moving forward."

Before that, on 18 February, Microsoft said it was monitoring the deployment and reaching out to a subset of affected users to verify the fix worked. No final remediation timeline was given then, and none has been published since.

What did not change is the control architecture that allowed the failure. The label and the DLP rule still describe intent; Copilot's retrieval path still enforces it. Microsoft's statement that its "access controls and data protection policies remained intact" is accurate as far as it goes — the policies were not altered or deleted — but it also means the policies were never the thing doing the blocking.

What the record establishes, and what it only asserts

Three tiers of claim sit inside this incident, and they are worth keeping apart.

Established: a code defect in the Copilot Chat work tab caused labelled, DLP-protected messages in Sent Items and Drafts to be summarised; Microsoft detected it on 21 January 2026, tracked it as CW1226324, began fixing it in early February, and said by 20 February that the root cause was addressed for most customers. Those facts come from Microsoft's own service alert and are corroborated by the BBC, IT Pro and TechCrunch.

Asserted by Microsoft, not independently verified: that no one gained access to information they were not already authorised to see; that the messages involved were authored by the affected user and limited to Outlook desktop; and that access controls and data protection policies remained intact throughout.

Not established by anyone: the number of affected organisations; the volume of messages processed; what happened to the content after summarisation; and whether any regulator has opened an inquiry. None of the coverage reviewed for this article names one.

Nader Henein, a data protection and AI governance analyst at Gartner, told the BBC that "this sort of fumble is unavoidable" given how often new AI capabilities ship, and that organisations would normally switch a feature off and wait for governance to catch up — but that the pressure created by AI hype makes that near-impossible. Professor Alan Woodward of the University of Surrey told the same outlet the incident shows why such tools should be private by default and opt-in only. Both are characterisations of the pattern rather than findings about this specific defect, and should be read that way.

The narrow lesson the record supports is less dramatic than the headlines and more useful: the control that failed was the one the customer had explicitly configured, and it failed in a layer the customer could not inspect. Microsoft's fix closed the code path. It did not give tenants a way to verify, independently, that the path stays closed.