M365 label gaps leave sensitive files outside Copilot controls

At a glance

What this is: This is an analysis of why Microsoft Purview sensitivity labels miss large portions of M365 content and how that creates Copilot exposure despite existing permissions.

Why it matters: It matters because IAM and security teams cannot treat label coverage as complete control coverage when AI assistants can inherit access to unlabeled sensitive files.

By the numbers:

• Purview policies do not cover 40% of your files in M365.
• Cyera says Microsoft Purview labeling leaves about 40% of M365 files outside label-based DLP.

Context

Sensitivity labels are only as effective as the file types they can actually touch. In this case, the control gap is not permissioning alone but the fact that many everyday M365 files such as CSVs, ZIPs, screenshots, code, and image-based PDFs sit outside the label-driven policy model.

That creates a Copilot governance problem as much as a data protection problem. If AI assistants inherit the same permissions users already have, then unlabeled content can remain readable even when the organisation believes DLP and encryption are in place.

The primary issue is coverage drift between what the policy framework assumes and what the estate actually contains. For identity and access teams, that means the effective control boundary is the file format, not the user role or the existence of a label.

Key questions

Q: What breaks when sensitivity labels cannot be applied to common file types?

A: The label-driven control chain breaks at the point where the file cannot be classified into the policy model. Without a label, Microsoft Purview cannot attach the downstream DLP, encryption, or Copilot rules that depend on it, so CSVs, ZIPs, screenshots, code, and image-based PDFs can remain visible even when teams believe they are governed.

Q: Why do unlabeled M365 files create Copilot risk even when permissions are correct?

A: Copilot inherits the same permissions users already have, so access alone does not solve the governance problem. If a sensitive file is unlabeled, the policy engine may never trigger, which means the assistant can still read and surface data that security teams expected to be covered by DLP or encryption.

Q: How should security teams govern sensitive data across mixed file formats?

A: Use content-based policy rather than label-only policy. Classify the data inside the file, not just the file type, and apply the same protection logic to Office documents, exports, archives, screenshots, and code so the control boundary follows the sensitivity of the content.

Q: What is the difference between label-based DLP and content-based DLP?

A: Label-based DLP depends on a file first receiving a sensitivity label, so it works best where the label structure is supported. Content-based DLP evaluates the data itself and can enforce policy across labeled and unlabeled files, which makes it better suited to mixed enterprise file estates.

How it works in practice

Why label-based DLP misses large parts of M365

Microsoft Purview sensitivity labels are designed around Office files and text-based PDFs, which makes them a metadata-driven control rather than a content-first control. That works when a file can be labeled, classified, and then governed through downstream DLP, encryption, and Copilot policy. It breaks when the file type is outside the labeling structure. In practice, the blind spot includes CSV exports, ZIP archives, screenshots, source code, and image-based PDFs, all of which can contain sensitive data without ever receiving a usable label.

Practical implication: Treat label coverage as partial control coverage, not full data governance.

Why Copilot exposure follows permission inheritance

Microsoft Copilot does not invent new access paths. It inherits existing permissions and can read whatever the user can read, which makes data security a problem of entitlement scope as well as content classification. If a file is unlabeled and therefore outside label-triggered policy, Copilot can still surface it when access exists. That means the security question is not only whether a user may open a file, but whether an assistant can process unprotected content that the label model never sees.

Practical implication: Review Copilot risk through the same entitlement lens used for other content access.

How content-based DLP closes the file-format gap

Content-based enforcement shifts policy from the label attached to the file to the data inside the file. Cyera’s model scans file contents directly, then applies the same sensitivity logic across labeled and unlabeled assets so that a PII finding in a Word document and a PII finding in a CSV export are handled consistently. This avoids creating two parallel governance programmes, one for office content and one for everything else. The key architectural change is that the policy decision happens on the content signal, not on whether the file format can accept a label.

Practical implication: Use content-based controls to apply one policy model across all file formats.

NHI Mgmt Group analysis

Label coverage is not control coverage: This article exposes a basic governance error in M365 programmes, which is assuming that a sensitivity label model defines the full policy boundary. It does not. When file formats cannot be labeled, the downstream DLP and Copilot protections attached to labels disappear with them. Practitioners should treat label-driven security as one control layer, not the control plane.

Content-based enforcement is the real gap closed here: The operational problem is not that organisations lack a label policy, but that policy attachment is format-bound while sensitive business content is not. CSV exports, ZIP archives, screenshots, source code, and image-based PDFs are common enterprise artifacts, so any governance model that excludes them leaves a predictable exposure lane. The implication is that identity and data controls need to follow the content, not the container.

Copilot turns dormant labeling gaps into active access risk: AI assistants do not create new permissions, but they do make existing blind spots more consequential because they can surface content at machine speed. That shifts the risk from occasional user access to repeatable, scalable retrieval of unlabeled sensitive material. The practitioner conclusion is that Copilot governance must be tested against unlabeled file populations, not only against the labeled corpus.

Unified coverage requires one policy model across mixed file states: The strongest pattern in the article is the move from dual treatment to one sensitivity model spanning both labeled and unlabeled content. Organisations that maintain separate handling paths for office documents and everything else usually discover the hard way that control inconsistencies become audit gaps. The practical outcome is a single inventory, a single risk view, and a single remediation queue for file security.

From our research library:

• Internal repositories are 6x more likely to contain secrets than public ones (32.2% vs 5.6%), contradicting the assumption that private repos are safe, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Coverage drift is the hidden risk in M365 governance: Teams often measure control maturity by the number of labeled documents, but the real question is whether the estate contains sensitive files that labels cannot touch. When file format determines policy reach, governance quality depends on inventory completeness rather than label adoption alone.

The practical test is whether a single risk view shows both the labeled corpus and the unlabeled residue. If not, then Copilot enablement and DLP reporting are operating on different control assumptions, which is how exposure persists even in environments that appear well governed.

For practitioners

• Map the unlabeled file estate Inventory CSV, ZIP, image, code, and image-based PDF files that hold sensitive data but cannot take sensitivity labels, then quantify where they sit in SharePoint, OneDrive, and connected stores.
• Test Copilot access against unlabeled content Validate whether Copilot can surface sensitive data from files that are permissioned but unlabeled, especially exports and screenshots that bypass label-triggered DLP.
• Move policy from labels to content Define protection rules on the data element itself, such as PII, financial records, source code, or regulated data, so the same rule applies regardless of file format.
• Unify the coverage view Build one inventory that shows labeled files, unlabeled files under content policy, and files outside both, then use that gap list as the remediation queue.

Key takeaways

• Sensitivity labels leave a structural blind spot in M365 when file formats cannot be labeled, and that blind spot becomes more visible once Copilot inherits user permissions.
• The article says roughly 40% of enterprise files can sit outside label-based DLP, with common examples including CSVs, ZIPs, screenshots, source code, and image-based PDFs.
• Security teams should shift from label-only governance to content-based policy so protection follows the data, not just the file container.

Key terms

• Sensitivity Label: A sensitivity label is a policy marker that signals how a document should be handled, such as Confidential, Internal, or Public. In practice, the label only matters if it is tied to enforcement in storage, sharing, and workflow systems, including the non-human identities that move the data.
• Policy-based DLP: Policy-based DLP is a traditional data loss prevention model that uses predefined rules, patterns, and inspection points to detect or block sensitive data movement. It works best in predictable environments, but loses accuracy when data flows become conversational, embedded, or highly dynamic.
• Label Coverage Gap: A label coverage gap is the portion of an information estate that cannot receive or use sensitivity labels, leaving downstream policy controls unavailable. In practice, it shows where governance assumptions stop matching the file formats people actually use.
• Permission Inheritance: The practice of allowing access on one object to flow into related objects through defined traversal rules. It reduces duplicate configuration, but it also creates hidden privilege paths that must be understood and reviewed. In complex systems, inheritance is often the real source of effective access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.