When an AI assistant enters the heart of business productivity, every logical flaw becomes a real risk. In recent days, Microsoft has confirmed a problem in Microsoft 365 Copilot that allowed the system to access and summarise emails labelled as confidential and theoretically protected by DLP and sensitivity labels. The event is tracked with the internal code CW1226324 and is not just a forum detail, but a textbook case of how language models intertwine with enterprise security controls.
What really happened
Copilot Chat, specifically the Work tab view, indexes and queries corporate content to build contextual responses. Under normal conditions, indexing should comply with Microsoft Purview labels and Data Loss Prevention policies. In this incident, however, some emails labelled as Confidential in Sent Items and Drafts still ended up in the pipeline, were processed by the retrieval engine and synthesised by the LLM. All this without the exclusion filters doing their job.
We are not talking about an external attack or an exfiltration-style data leak. It is a server-side logic flaw: the controls that should have stopped sensitive content before the inference phase did not apply the rules correctly. The practical result: legitimate users obtained summaries that should not have existed, and security teams did not receive an automatic warning.
Why it matters
This incident highlights three issues that every company should already be addressing.
Policy enforcement within AI pipelines
Traditional DLPs are designed to block data leakage or unauthorised use. Here, the problem is internal to the service, and therefore invisible to tools that monitor the external boundary. If the policy is not respected along the indexing chain, the AI can produce an output that is functionally correct but wrong from a risk perspective.
LLM trust boundaries
A language model is not an isolated process. It thrives on retrieval, caching, and orchestrators that pass data back and forth. If a labelling or filtering anomaly passes upstream, the LLM will do its job with the data it receives. The golden rule remains valid: confidential data should never reach the inference stage, and the controls that ensure this must be explicit, verifiable, and independent.
Compliance and accountability
Even without exporting to third parties, generating summaries from content covered by confidentiality labels can conflict with privacy by design principles and access control requirements under the GDPR or sector-specific regulations. This is not just a technical issue, it is a governance issue.
The timeline in brief
According to public reports, the anomalous behaviour began on 21 January 2026 and was detected through internal telemetry. Between late January and early February, the problem manifested itself in multiple tenants, then in February a server-side correction was initiated, with targeted communications to customers to confirm the remediation. Timing and methods are important because they tell us two things: the detection took place in-house and the fix does not require client intervention, so the defect was in the logic of the central service.
What to do now, in practical terms
Net of the patch, now is the time to put your AI security design to the test. Some pragmatic actions help turn the lesson into operational control:
- Pre-LLM policy testing: use labelled synthetic datasets to verify that confidential content is not indexed or passed to the inference layer. It is not enough to control access to the file; the entire retrieval chain must be validated.
- Dedicated auditing and telemetry: track when an AI assistant accesses data classes that should be excluded. You need specific logs for AI pipelines and alerts on scope violations, not just generic SIEM and XDR rules.
- Explicit trust boundaries: establish verifiable block points before the prompt and completion phase. Exclusion decisions should not only live within the indexer; they should be duplicated and validated upstream.
- Risk ownership: treat AI as an asset with its own risk profile. Update the risk register, define compensating controls and a regression testing plan whenever the configuration or cloud service changes.
The bottom line
This is not your usual release note with a bug fix. It is a reminder that AI in business workflows requires a security model that understands the behaviour of LLMs and their dependencies. Classic controls remain essential, but they are not enough if they are not projected into the retrieval and generation pipelines. The call to action is clear: language models must be treated as risk components in their own right, with measurable policies at every point where they touch sensitive data.
Analysis by Vasily Kononov – Threat Intelligence Lead, CYBEROO
