Copilot for Microsoft 365 respects sensitivity labels and encryption

Whenever Copilot for Microsoft 365 comes up in a real project, one of the first questions I get is how it keeps sensitive data from being exposed. The answer has a lot to do with sensitivity labels. If you want your organization's data to stay out of the wrong hands, you need to understand how the two work together. In my experience, many admins treat Copilot as something "magic" that sidesteps the basics of Microsoft Purview Information Protection. The reality is the other way round. Copilot sticks strictly to access controls, sensitivity labels and encryption settings. That sounds simple enough, but a few details still trip up experienced teams.

Usage rights decide which encrypted files Copilot can use

The basic rule is easy: Copilot only touches content the user can access. With files protected by sensitivity labels, and especially labels that apply encryption, Copilot is bound by the permissions the user actually holds. One point people often miss is that Copilot can only extract or summarize content if the user has both the "EXTRACT" and "VIEW" usage rights. If an encrypted file allows viewing but not extracting, Copilot leaves it out of its responses. "Do Not Forward" or tightly restricted rights therefore keep Copilot away from those documents. The official documentation explains this clearly, and I bring it up in every Copilot deployment workshop I run.

Before I get to the diagram, one practical tip from my own projects:

Keep your sensitivity labels clear, few in number and well communicated. Confusion and label sprawl hurt security and usability alike.

This is how Copilot handles content depending on sensitivity labels and rights:

flowchart TD
  user["User"] --> copilot["Copilot for Microsoft 365"]
  copilot --> doc1["Labelled file (VIEW only)"]
  copilot -.->|"No access"| doc1
  copilot --> doc2["Labelled file (VIEW+EXTRACT)"]
  copilot -->|"Access allowed"| doc2
  copilot --> doc3["Unlabelled file"]
  copilot -->|"Access allowed"| doc3

Figure: Copilot only processes content the user has sufficient rights to.

I regularly run into a misunderstanding here. Some people think any label with encryption automatically blocks Copilot, but the actual usage rights are what count. If there's something Copilot should never see, look closely at those rights.

Copilot passes the strictest label on to its responses

This one is easy to miss. When Copilot creates new content, for example a summary, a draft or an email, it automatically applies the highest-priority sensitivity label found in the source files. The inheritance works reliably as long as labels are published correctly and actually applied to the source data. If a query pulls from mixed content, say "internal" and "confidential" documents together, the strictest label wins, so sensitive material doesn't end up in output with weaker protection. Copilot also shows the labels in its responses, along with references to the source documents. That supports compliance and keeps users aware of what they're handling day to day. For the finer points of how label priority works, the Microsoft documentation is a good reference.

A lean label taxonomy with defaults and auto-labeling lays the groundwork

To get Copilot and sensitivity labels working properly, the basics have to be in place first. Begin with a simple label taxonomy. Three or four clear levels such as "Public", "Internal", "Confidential" and "Strictly confidential" are enough for most organizations. Set a default label for new documents so nothing gets overshared by accident, and turn on automatic labeling for sensitive information types (credit card numbers or personal IDs, for instance) to catch mistakes early. Also use container labels for SharePoint sites and Teams, so new content gets the right label from the start. I covered the fundamentals of Purview classification and auto-labeling in more depth here.

This is the PowerShell line I've used to set a default label on a SharePoint site:

Set-SPOSite -Identity https://contoso.sharepoint.com/sites/Finance -SensitivityLabelId "<label GUID>"

If you're rolling out Copilot, keep in mind that Microsoft Purview audit logs record Copilot activities, showing who accessed or summarized what and when. That gives you more transparency and makes regulatory reporting easier.

Copilot and sensitivity labels still have some gaps

Not everything works perfectly yet. As of April 2024, I'd flag a few limitations. Some encrypted content types aren't fully respected in every scenario, particularly with third-party clients or unsupported file formats. Label inheritance depends on the Microsoft 365 Apps, and older or classic Office clients may not behave as you'd expect. Auto-labeling at scale can also take longer than planned, especially across large legacy data sets. Keep expectations realistic. Copilot and sensitivity labels work well together, but they won't solve every problem.

Classification is the safety net every Copilot rollout needs

Rolling out Copilot for Microsoft 365 without solid sensitivity labels and encryption is asking for trouble. Over time I've stopped seeing labels as a compliance checkbox. For me they're the actual foundation for using AI securely and responsibly in Microsoft 365. Clear labels, carefully chosen rights and Purview auditing make your data much harder to leak, whether by accident or on purpose. If you take labels seriously, Copilot becomes an assistant you can trust. If you treat them as an afterthought, expect some unpleasant surprises. For more on getting your tenant ready, see my post on Copilot for Microsoft 365 readiness.