The Promise

Microsoft 365 Copilot Chat is sold on a simple bargain: let the assistant read enough of your work to be useful, and trust Microsoft to keep that access inside the guardrails. In an enterprise setting, those guardrails are not decorative. Sensitivity labels, DLP policies, and mailbox controls exist because companies keep confidential drafts, legal discussions, security notes, and internal planning documents inside Outlook all day long. If the AI assistant is told not to touch protected content, "not touching protected content" is not an aspirational product goal. It is the feature.

In February 2026, Microsoft had to admit that Copilot Chat had been ignoring that boundary for some users.

The issue, tracked as CW1226324, affected the Microsoft 365 Copilot "work tab" chat feature. According to Microsoft's own service notice, emails in Drafts and Sent Items with confidential labels applied were being incorrectly processed by Copilot even when a Copilot DLP policy was configured. The NHSmail support bulletin published the blunt version of the diagnosis: "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."

That is an unusually concise way to describe a security boundary failure.

What Actually Broke

The affected messages were not random inbox mail. They were messages authored by the user and stored in Sent Items or Drafts. That detail matters because it explains Microsoft's defense and also why the defense did not land especially well.

Microsoft's public line, repeated to BBC News and BleepingComputer, was that the bug "did not provide anyone access to information they weren't already authorized to see." In the narrowest possible access-control sense, that is true. The user whose drafts were being summarized by Copilot already had permission to read those drafts. The system was not, so far as Microsoft said publicly, handing Alice's protected messages to Bob.

But that framing dodges the actual failure. The problem was not merely who could read the message. The problem was that protected content was being fed into a system that policy and product controls were explicitly supposed to exclude. If an organization sets a sensitivity label and a Copilot DLP policy to keep certain material out of the assistant, then the assistant processing that material anyway is the incident.

It is the same reason "the employee already had access to the file" would not excuse a data-loss-prevention product that ignored classification rules and sent restricted files through an external workflow. The whole point of the rule is to stop that workflow from happening.

Why Drafts And Sent Items Matter

Drafts and Sent Items are not glamorous folders, but they are where a lot of the interesting material lives. Drafts hold unfinished contract language, half-written HR notes, legal edits, security incident comms, internal negotiations, and the version of an email people write before they decide how much they really want to say. Sent Items hold the message that actually went out, which in many organizations is the authoritative record of what was communicated and when.

Microsoft did not disclose how many customers were affected. It also did not say what types of organizations were in scope beyond acknowledging the issue publicly and rolling out a fix. The NHSmail bulletin at least established that regulated public-sector users were watching the incident closely enough for the alert to appear on a health-system support portal. That does not mean patient data leaked. NHSmail explicitly said patient information had not been exposed. It does mean the bug landed in exactly the kind of environment where people buy sensitivity labels and DLP controls because guessing wrong is expensive.

The Timeline

BleepingComputer reported that Microsoft first detected the issue on January 21, 2026. A public NHSmail support alert describing the bug appeared on February 4. TechCrunch reported the bug on February 18. BBC News followed on February 19 with Microsoft's statement that a configuration update had been deployed worldwide for enterprise customers. The NHSmail notice marked the incident resolved on February 24 after Microsoft said the targeted fix had saturated across impacted environments.

That timeline is not evidence of a cover-up. It is fairly standard enterprise-software incident handling: identify the bug, push the fix, update customer channels, answer reporters after the issue becomes public. Still, it means there was a window of weeks in which protected email content could be processed by Copilot in ways customer policy was supposed to prevent.

The "Secure AI For Work" Problem

Copilot Chat is not a toy chatbot asking whether you want a haiku about spreadsheets. It is a work assistant embedded into products that companies use to run finance, legal, procurement, HR, and ordinary office life. Microsoft markets that integration as the reason customers should trust the system with real business information. The more deeply the assistant can search, summarize, and recombine workplace data, the more useful it becomes.

That utility depends on customers believing the boundaries actually work.

A bug like CW1226324 lands directly on that trust line. It tells customers that the system may respect permissions in the broad sense while still ignoring the finer-grained policy controls they paid for to keep protected material away from AI processing. For an ordinary software search feature that would already be a problem. For an AI assistant that rewrites and summarizes content into new outputs, the concern is sharper, because the system is not just indexing the material. It is transforming it into an answer.

Once that answer appears in a chat window, the argument that "no unauthorized person saw it" starts to sound like legal positioning rather than reassurance. The assistant was not supposed to be in the room at all.

Familiar Pattern, Different Flavor

Microsoft already has other Copilot stories in this graveyard because its AI products keep finding new ways to turn convenience into attack surface. EchoLeak was about zero-click exfiltration. Reprompt was about single-click prompt injection and data theft. This incident is less cinematic. There was no clever attack chain, no hostile document, no attacker-controlled server waiting on the other end.

It was a product bug. A boring one, in the sense that "code issue ignores policy condition" is the oldest sentence in enterprise software. Boring bugs still count when they happen inside systems that are supposed to mediate access to sensitive information with extra care because there is now an LLM in the loop.

Microsoft fixed it. Good. That is the minimum expected outcome.

The reason the incident belongs here is that Copilot Chat was allowed to cross a policy boundary its own product design told customers they could rely on. The labels were there. The DLP policy was there. The assistant read the messages anyway. That is not a philosophical concern about AI trust. That is a shipped enterprise feature doing the wrong thing in production.