Microsoft Copilot Ignored Sensitivity Labels, Processed Confidential Emails
For weeks, Microsoft 365 Copilot quietly read, summarized, and surfaced emails that organizations had explicitly marked as confidential.
Legal memos. Business agreements. Government correspondence. Protected health information. All processed by an AI that was never supposed to touch it.
The bug — tracked as CW1226324 — was first reported by customers on Jan. 21, 2026. Microsoft didn’t begin rolling out a fix until early February. As of mid-February, remediation still isn’t complete. The UK’s National Health Service flagged the issue internally. And Microsoft still hasn’t said how many organizations were affected.
Here’s the part that should keep every security leader up at night: The sensitivity labels were in place. The data loss prevention (DLP) policies were configured correctly. Every box was checked. And none of it mattered.
What actually broke
The details are frustratingly straightforward.
A code error in Copilot Chat’s “Work” tab allowed the AI to pull emails from users’ Sent Items and Drafts folders — even when those emails carried confidentiality labels and had DLP rules explicitly configured to block AI processing. The labels said “hands off.” Copilot ignored them.
Microsoft’s public response was carefully worded: Users only accessed information they were already authorized to see. Technically true. Also entirely beside the point.
The question was never whether the user had clearance. The question is whether the AI was authorized to ingest, process, and summarize confidential content. It wasn’t. The policies said so. The code disagreed.
The deeper problem nobody wants to talk about
This isn’t a story about one bug. Bugs happen. Code ships with errors. Patches roll out.
The real story is architectural. Every security control that was supposed to prevent this — sensitivity labels, DLP policies, access restrictions — lived inside the same platform as the AI itself. When the platform broke, everything broke. No second layer. No independent check. No backstop.
Think of it this way: Imagine a bank where the vault door, the alarm, and the security cameras all run on a single circuit breaker. One tripped wire, and you’ve got an open vault, no alarm, and no footage. That’s what happened here.
And this isn’t a theoretical risk anymore.
The World Economic Forum’s 2026 Global Cybersecurity Outlook found that data leaks through generative AI are now the number one cybersecurity concern among CEOs globally, cited by 30% of respondents. The WEF report also warned that roughly one-third of organizations still have no process to validate AI security before deployment. The Copilot incident is what that gap looks like when it hits production.
Why ‘trust but verify’ fails when the verifier is also the vendor
Microsoft is both the AI provider and the entity responsible for the controls governing that AI. When those controls failed, organizations had no independent way to know. They found out when Microsoft told them — weeks later.
No independent audit trail. No anomaly detection flagging unusual access patterns. No real-time alerting when Copilot suddenly started processing confidential content it had never touched before. Just silence, then a service advisory.
This is the governance gap that platforms like Kiteworks are built to address. Their argument — and the Copilot bug makes it hard to disagree — is that AI governance controls need to operate on a separate layer from the AI platform itself. Not as a policy within the same ecosystem. As an independent control plane.
The logic is straightforward: If AI must authenticate through an external governance layer before touching sensitive data, a bug inside the AI platform doesn’t automatically grant access to everything. Purpose binding restricts which data classifications AI can process. Least-privilege access means AI agents get only what they need, not broad access to entire repositories. And independent audit trails mean you know what happened regardless of what the vendor’s logs show.
Compliance time bomb
Here’s where it gets expensive.
If Copilot processed emails containing protected health information — and the NHS flagged this internally, so that’s not hypothetical — organizations may face breach notification obligations under HIPAA. If GDPR-covered personal data was processed, Article 32’s requirement for “appropriate technical measures” comes into play. Telling a regulator your sole safeguard was a vendor control that failed for weeks is a tough sell.
The EU AI Act’s Article 12 record-keeping requirements add another wrinkle. If your only evidence of what the AI accessed comes from the vendor that had the failure, that’s a documentation gap no legal team wants to inherit.
What comes next
The fix is not to stop using AI. That ship has sailed. The fix is to stop treating AI platform controls as sufficient on their own.
Defense in-depth isn’t new. We don’t protect networks with a single firewall. We don’t secure buildings with just a front door lock. But somehow, we’ve been trusting AI governance to a single layer of sensitivity labels managed by the same platform running the AI.
The Copilot bug didn’t reveal a new risk category. It confirmed one that security leaders have been warning about since enterprise AI adoption took off. The organizations that weather these incidents — and there will be more — are the ones building independent governance now, before the next service advisory lands.
The labels were in place. The policies were configured. And the AI read your confidential emails anyway.
If that doesn’t change how you think about AI governance, what will?
Also read: The Reprompt attack shows how a single link can hijack Copilot sessions and exfiltrate data.
About Author
