On January 21, 2026, Microsoft identified a bug in M365 Copilot Chat that had been silently reading and summarizing confidential emails — bypassing the DLP policies and sensitivity labels deployed specifically to prevent it. That same month, researchers documented a sharp surge in OAuth device code phishing campaigns targeting North American businesses — attacks that bypass both passwords and MFA, issuing persistent access tokens to attackers without a single credential being stolen.

Neither of these was a zero-day. Both were configuration-layer failures hiding in plain sight.

The common thread across these incidents and the LexisNexis breach in early March is the same: organizations believed a control was in place. It wasn’t. Microsoft’s own platform introduced the DLP gap. Attackers exploited an authentication flow that nobody had explicitly restricted. An unpatched frontend sat exposed for months because nobody was enforcing the patch state as infrastructure.

Traditional compliance doesn’t catch this. An MSP configures DLP labels, documents the settings, and closes the audit ticket. A point-in-time review confirms the policy exists. But configuration drift is silent — platform bugs get introduced, settings get changed, new features ship with unexpected behavior. Static documentation won’t detect when Copilot starts ignoring your sensitivity labels. A compliance checklist won’t block an OAuth device code flow that was never explicitly restricted at the Conditional Access layer.

What WaypointX Changes

The Copilot DLP incident maps directly to WaypointX’s DLP baseline enforcement. WaypointX declares DLP policy configurations — including sensitivity label enforcement and Copilot interaction rules — as infrastructure state via the Microsoft Graph API and PowerShell-invoked Exchange Online policies. When Microsoft ships a platform change that introduces unexpected behavior, the next compliance run flags the drift and re-enforces the correct state. That’s the difference between a policy that “exists” and a control that’s continuously verified. SOC 2 CC6.7 requires that data loss prevention controls be implemented consistently — not configured once and assumed to persist. WaypointX enforces that consistently.

The OAuth attack vector is equally direct. WaypointX’s Conditional Access baseline includes an explicit policy restricting the device code authentication flow for user accounts — removing the attack surface for organizations that don’t require it. That restriction is declared at the tenant level and enforced on every run. The attack assumes the flow is available by default. WaypointX removes that assumption. That satisfies CC6.1 (logical access controls) and CC6.3 (OAuth application governance).

For MSPs serving law firms, accounting practices, and healthcare organizations, these incidents create a real conversation. Clients who believe their DLP policies are protecting them need to understand that “configured” is not the same as “continuously enforced.” Cyber insurers and compliance auditors increasingly ask for evidence of control enforcement — not screenshots of settings. WaypointX gives MSPs a defensible answer to both questions, and a recurring revenue model built around delivering it.

If your clients’ compliance posture is enforced by policy documents rather than infrastructure code, the next platform bug isn’t their auditor’s problem. It’s yours.