For nearly a month, Microsoft’s AI assistant ignored the labels enterprises use to protect sensitive data. The fix took two weeks to acknowledge. The audit trail never came.
Microsoft confirmed this week that a bug in Microsoft 365 Copilot allowed its AI to read and summarize confidential emails that were supposed to be off-limits. Emails tagged with sensitivity labels. Emails protected by data loss prevention policies. The kind of emails that exist behind guardrails specifically because their contents could trigger compliance violations, expose trade secrets, or blow up negotiations.
Copilot ignored all of that and summarized them anyway.
The bug, tracked internally as CW1226324, affected emails in users’ Sent Items and Drafts folders. If those emails carried confidentiality labels, Copilot was supposed to leave them alone. Instead, a “code issue” (Microsoft’s term) allowed the AI’s chat feature to pick them up, process them, and serve summaries back to users. In some cases, it surfaced emails from shared mailboxes to people who didn’t have permission to view them.
Customers first reported the issue on January 21st. Microsoft didn’t acknowledge it until February 3rd. The fix started rolling out in early February, but as of this writing, Microsoft hasn’t disclosed how many organizations were affected, hasn’t provided a full remediation timeline, and hasn’t offered tenants an audit trail showing which queries accessed which protected items during the exposure window.
That last part matters. A lot. Organizations bound by HIPAA, GDPR, SOX, or SEC disclosure rules need to prove that confidential data wasn’t improperly accessed. Without audit logs, they can’t. Microsoft is essentially saying: trust us, we fixed it. For regulated industries, trust isn’t a compliance strategy.
“A Bug We Fixed” Is the Wrong Frame
Microsoft wants this to be a story about a code error that got patched. That framing only works if you don’t look at the pattern.
Last August, security researchers at Zenity demonstrated at Black Hat how prompt injection attacks could make Copilot silently harvest emails and exfiltrate data through invisible Unicode characters. The technique, called ASCII smuggling, let attackers embed data into clickable hyperlinks that looked normal to users but contained stolen information. Microsoft classified that one as critical severity.
Before that, in March 2024, the U.S. House of Representatives banned all congressional staff from using Copilot on government devices. The reason: the Office of Cybersecurity determined it could leak House data to non-approved cloud services. Microsoft responded with promises about future federal compliance tools.
In January 2026, researchers at Varonis published details on a “Reprompt” attack, a single-click technique that could silently exfiltrate personal data from Copilot sessions. And just this month, Zenity Labs disclosed that Copilot Studio’s “Connected Agents” feature, enabled by default on all new agents, allows lateral movement between AI agents without explicit administrator approval.
This isn’t one bug. This is a pattern. And the pattern points to something that can’t be patched with a code fix.
The Structural Problem Nobody Wants to Name
Copilot doesn’t have its own access control system. It inherits permissions from the Microsoft 365 environment underneath it. If a user can see a file, Copilot can see that file. If a folder has overly broad sharing settings (and after years of collaboration sprawl, most do), Copilot can access everything in it. At machine speed. Across every document, email, and Teams conversation the user has touched.
Research from Concentric AI found that 16% of business-critical data in typical organizations is overshared. That’s 802,000 files on average, sitting in environments with inherited access, unreviewed permissions, and collaboration settings nobody has audited since 2019. Copilot doesn’t create that mess. But it makes it exploitable in ways that weren’t possible before.
Security Magazine ran a piece titled “The Copilot Problem: Why Internal AI Assistants Are Becoming Accidental Data Breach Engines.” The core observation: an employee asked their AI assistant a routine question, and the answer referenced emails, legacy files, and internal records the user didn’t know still existed. No hack. No policy violation. The system worked exactly as designed.
That’s the part Microsoft doesn’t want to talk about. The DLP bypass was a bug. The oversharing exposure isn’t. It’s the architecture working as intended, in environments that were never built to withstand an AI that can read everything.
Every security vendor on the planet will use this story to sell data governance tools for the next six months. Permission hygiene. Sensitivity audits. Zero-trust frameworks for AI access. They’re not wrong. Oversharing is real, and Copilot makes it exploitable faster. But that framing also happens to be the version of the story with a product attached to it.
Two Weeks and No Receipts
The version without a product attached is simpler and worse.
Sensitivity labels worked for years. DLP policies worked for years. Microsoft built functioning guardrails, and then a code regression broke them. That happens in software. What happened next is the part that should keep CISOs awake.
Customers reported the issue on January 21st. Microsoft acknowledged it on February 3rd. Thirteen days where affected organizations didn’t know their confidentiality controls were broken. When the fix finally started rolling out, Microsoft provided no audit trail. No scope disclosure. No way for affected tenants to trace which Copilot queries accessed which protected items during the exposure window.
For a company running HIPAA workloads, that’s not an inconvenience. That’s a compliance investigation with no evidence trail. You can’t go to an auditor with “Microsoft says they fixed it.” You need logs showing what was accessed, by whom, and when. Those logs don’t exist.
The architecture debate will dominate the next quarter of conference talks and vendor pitches. It’s the comfortable conversation, the one where the answer is “buy better tooling.” But tooling doesn’t explain why Microsoft sat on customer reports for nearly two weeks. Tooling doesn’t explain why the remediation came without documentation that regulated industries need to prove compliance wasn’t violated.
The bug is patched. The permissions debate will continue. Neither of those is the actual story. The actual story is that when Microsoft’s own safeguards failed, their response left customers unable to prove what happened during the window. For organizations where proof isn’t optional, that’s the thing that can’t be fixed retroactively.