The Copilot Problem Is a Data Hygiene Problem

Your Copilot deployment did not create a new security risk. That risk has been there since the beginning, and it will be there until you stop blaming new tech and start focusing on the underlying issue.

In the months since Microsoft 365 Copilot became broadly available inside enterprise tenants, a particular kind of incident report has been accumulating in security teams across regulated industries.

An employee asks Copilot a benign question and receives an answer that references a document they should not have been able to see. A junior analyst prompts Copilot for quarterly revenue projections and receives an executive compensation summary. A project manager asks for a status update on an internal initiative and is surprised to find Copilot citing the organization's merger term sheet.

These incidents are not failures of Copilot; in fact, Copilot is behaving exactly as designed. It respects the permissions set on the underlying files. It honors sensitivity labels when they are applied. It operates within the boundaries the organization has configured. The problem is that, for most enterprises, those boundaries were never configured with the specificity that AI-powered retrieval now requires.

According to Concentric AI's 2025 Data Risk Report, Microsoft Copilot accessed nearly three million sensitive records per organization in the first half of 2025 alone. The figure comes from telemetry across Concentric's customer base in technology, healthcare, government, and financial services. The same report found organizations averaging over 3,000 Copilot interactions in that window and 55-57% of externally shared files containing privileged or sensitive content.

This is the compounding effect of years of permission drift on SharePoint libraries, OneDrive folders shared with "anyone in the organization", legacy Teams sites with forgotten guest access, and classification schemes that were designed for human users clicking through folders rather than an AI assistant capable of surfacing any document in seconds. Before Copilot, over-permissioned data was a latent risk. After Copilot, it is an active one. Behold: the future.

The reason this matters now, rather than five years ago, is that traditional defenses were never designed for retrieval at this speed. Role-based access control assumes a human in the loop who will not realistically search for and read every document they technically have permission to access. Classification programs were built around the assumption that users would see labels and behave accordingly. DLP policies were written for the scenarios security teams anticipated, which is to say, scenarios that involved a person deliberately attempting to move data outside the organization. But, Copilot changes all of these assumptions.

An AI assistant does not need to browse folders to find what it wants, it queries an index. It does not care whether a document is buried in a personal OneDrive, embedded in an email attachment, or sitting in a Teams chat from 2019. If the user is technically permitted to see it, Copilot can retrieve it, summarize it, and present it in response to a question that did not explicitly ask for it. This is the intended behavior of a retrieval-augmented AI system operating on top of an access control model that predates retrieval-augmented AI systems.

The uncomfortable conclusion is that most organizations are having a data security hygiene problem that Copilot has made visible.

There are four specific conditions that create the exposure, and they tend to exist simultaneously in most Microsoft 365 environments.

The first is permission inheritance from shared workspaces

When a SharePoint site was created for a project three years ago and made accessible to an entire department, every document added to that site inherits that access. If sensitive documents were later placed in that site (because it was the convenient location, or because the person saving them did not realize the site's permission scope) those documents inherit the broad access whether or not that was the author's intent. Copilot surfaces them because the permissions technically permit it.

The second is inconsistent sensitivity labeling

Organizations that deployed Microsoft Information Protection often did so as a pilot, published a taxonomy of labels, and then never extended mandatory labeling to the full environment. The result is that some documents carry labels and are protected accordingly, while a much larger population of equivalently sensitive documents carries no label at all and is treated as unclassified. Copilot does not distinguish between "this document has no label because it is genuinely public" and "this document has no label because no one ever labeled it." Both are retrievable, to the chagrin of all involved.

The third is unindexed or unclassified sensitive content in workloads that sit outside most labeling programs

Exchange Online mailboxes illustrate the problem clearly. In January 2026, Microsoft confirmed a Copilot bug (CW1226324) that caused Copilot Chat to summarize confidential emails in Sent Items and Drafts folders, bypassing both sensitivity labels and DLP policies that were explicitly configured to prevent that behavior. Microsoft acknowledged that confidential content was processed by Copilot in ways the organization explicitly prohibited. Orgs that had not separately inventoried and classified their mailbox content at rest had no independent way to reliably detect or verify exposure when Microsoft's platform controls failed.

The fourth is the shadow AI layer

Employees using consumer AI tools outside the sanctioned Copilot deployment are pasting sensitive data into prompts that travel outside the tenant entirely. Microsoft's own research acknowledges this as a significant and growing risk, which is part of why Edge for Business now includes prompt-level DLP powered by Purview, which is in fact an admission that the problem has outgrown perimeter controls.

The remediation is the work of building a functioning data security architecture on top of the Purview capabilities already included in E5 licensing.

That architecture has three components, and each one maps to a specific Purview capability that most organizations own but have not yet operationalized.

1. Before any policy can be written responsibly, the organization needs to know where its sensitive data actually lives. This includes which SharePoint sites contain regulated content, which mailboxes hold documents that would trigger compliance obligations if exposed, which OneDrive accounts accumulated sensitive material through years of everyday work. This requires systematic scanning rather than sampling, and it requires tooling that produces exportable, actionable output rather than point-in-time dashboard views. Microsoft's native Content Search and Data Security Posture Management capabilities cover portions of this, but Exchange Online mailbox content at rest remains a gap that often requires custom tooling to close.
2. Auto-labeling policies in Purview can classify content based on sensitive information type detection, trainable classifiers, and contextual rules. Configured with sufficient precision these policies can retroactively apply sensitivity labels to the existing corpus of unlabeled content, which in turn enables encryption, access restrictions, and downstream DLP enforcement. This is the single highest-leverage intervention available inside Purview, and it is the one most organizations have deferred because it requires architectural attention that exceeds what a product deployment alone can deliver.
3. Purview DLP now supports prompt-level inspection in Copilot and in Edge for Business. Policies can audit or block sensitive data submission to AI tools in real time. This does not replace the underlying classification work, it assumes it, but it closes the loop by preventing sensitive data from flowing into AI contexts whether those contexts are Copilot itself or external AI tools accessed through the browser.

None of this is net-new technology. All of it exists inside Purview today, included in E5 licensing that most affected organizations purchased years ago. The gap between what the platform can do and what most organizations have actually configured is the gap that Copilot deployments are now exposing, and closing it is a question of architecture.

The Copilot problem will not resolve itself. Read it again. Recite it every morning you find yourself thinking that it will. The AI assistants are becoming default features of productivity suites rather than optional add-ons. The data exposure pattern that has emerged over the past eighteen months is not a phase that will pass. It is the new baseline condition, and organizations that have not yet experienced a Copilot-surfaced incident are not safer than those that have. They are earlier in the timeline.

The organizations that will navigate this well are those that treat Copilot deployment not as an AI initiative but as a forcing function for the data security work that has been deferred since E5 licensing was first purchased. The work is not glamorous. It consists of inventorying what exists, labeling what matters (not what your users think matters), and enforcing policies that distinguish between the two. It is exactly the work Purview was built for. It is exactly the work most organizations have not yet done.

If that description of the gap between current state and required state is uncomfortably specific to your environment, the gap is closable. It requires technically precise, sustained architectural work, but it is work that can begin with an honest assessment of where sensitive data actually resides in the tenant today instead of where policies assert it should be.

Matt Silcox is a Microsoft MVP in Purview Data Security and the practitioner behind Severian Technology Group. He writes about the technical reality of Microsoft Purview implementations at severian.ghost.io and severiansecurity.com.