Governing Microsoft 365 Copilot with Purview: Applying Compliance Controls to AI Interactions

Introduction

Microsoft 365 Copilot is rolling out across organisations faster than most compliance teams can keep up. Your marketing team is asking Copilot to summarise strategy documents. Your finance team is drafting emails with Copilot referencing Q3 numbers. Your legal team is querying Copilot about contract terms. Every one of these interactions involves your data – documents labelled Confidential, spreadsheets containing financials, emails with client names.

The question is not whether to allow Copilot. It is already in use. The question is whether your existing compliance controls apply to it. They do – if you configure them correctly. Microsoft Purview’s DLP, sensitivity labels, audit log, and retention policies all extend to Copilot interactions. This guide walks through exactly how to configure each control for Copilot specifically, based on deployments I have done for organisations adopting Copilot across finance, legal, and HR teams.

If you have not yet set up the foundational Purview controls, start with the first-day setup guide and the AI-powered compliance guide. This guide assumes you have sensitivity labels, DLP policies, and audit logging already running.

How Copilot Interacts with Your Data – and Where the Risks Are

To govern Copilot effectively, you need to understand what it accesses and when. Copilot does not have blanket access to your Microsoft 365 data. It respects existing permissions. When a user asks Copilot to summarise a document, Copilot can only access documents that user already has permission to read. When a user asks Copilot to draft an email referencing meeting notes, Copilot searches across the user’s own mailbox, OneDrive, and accessible SharePoint sites.

This permission-respecting architecture is the foundation of your governance strategy. It means your existing sensitivity labels already protect Copilot interactions – a user without access to a Confidential document cannot ask Copilot to summarise it, because Copilot cannot see it either. But there are gaps. A user with access to a Confidential document can ask Copilot to summarise it, and the summary may contain sensitive content in a new, unlabelled format. That summary can then be shared, forwarded, or copied without the original document’s protections.

The risks are not in what Copilot can access – it can only access what the user can. The risks are in what happens to the data after Copilot processes it. The summary, the draft email, the generated report – these are new documents created from sensitive source material. If they are not automatically labelled, they escape your classification controls. Governing Copilot means closing this gap.

Applying DLP Policies to Copilot Prompts and Responses

Your existing DLP policies already cover Copilot interactions, but you need to verify this. Copilot prompts and responses flow through Exchange Online and SharePoint, which means DLP policies scoped to those locations will evaluate Copilot content. If a user pastes a credit card number into a Copilot prompt, and you have a DLP policy blocking credit card data in Exchange, that policy will fire.

The gap most organisations miss is that Copilot can generate sensitive content from non-sensitive prompts. A user asks Copilot to draft a project update email. Copilot pulls data from a SharePoint site containing budget figures and includes them in the draft. The prompt contained no sensitive data, but the response does. Your DLP policy must be configured to scan both sides of the interaction – the prompt and the response.

To test this, create a DLP policy with a simple sensitive info type, scope it to Exchange, and run it in simulation mode. Then ask Copilot to generate content that might include that sensitive info type based on documents you know exist in your environment. Check Activity Explorer to see whether the policy matched. If it did not, your DLP configuration may need to be extended to cover the specific Exchange transport paths Copilot uses. This is an evolving area – Microsoft updates Copilot’s integration with Purview regularly, so revalidate your DLP coverage quarterly.

Sensitivity Label Inheritance: Ensuring AI Outputs Stay Protected

The most important Copilot governance feature is label inheritance. When Copilot generates content based on a labelled source document, the output automatically inherits the source document’s sensitivity label. If a user asks Copilot to summarise a document labelled Highly Confidential, the summary is automatically labelled Highly Confidential. The protection travels with the data.

Label inheritance works automatically for documents stored in SharePoint and OneDrive. It is not configurable – it is on by default and cannot be turned off. This is by design. Microsoft made a deliberate governance choice to prevent AI-generated content from escaping classification controls. The inheritance applies to the highest classification level of any source document Copilot references. If Copilot pulls data from an Internal document and a Confidential document to generate a single response, the response inherits the Confidential label.

Verify that label inheritance is working in your environment. Create a test document labelled Confidential, ask Copilot to summarise it, and check the sensitivity label on the output. It should show Confidential. If it does not, your labels may not be published correctly or the user account may not have the appropriate licences. The sensitivity labels guide covers label publishing and troubleshooting. You should also verify that label inheritance respects your encryption settings – a summary of an encrypted document should be encrypted with the same permissions as the source.

Auditing Every Copilot Interaction and Retaining AI-Generated Content

Every Copilot prompt and response is captured in the unified audit log. The event type is CopilotInteraction. Each record includes the user, the prompt text, the response text, the documents Copilot referenced, and the sensitivity labels inherited. This audit trail is comprehensive and searchable through the standard audit log interface.

Create a saved search for CopilotInteraction events filtered to prompts that reference documents labelled Confidential or higher. Run this search weekly. It shows you who is querying sensitive data through Copilot and what they are asking. Most of it will be legitimate work. Some of it will be users testing boundaries – asking Copilot to summarise documents they should not be sharing, or querying sensitive data in ways that circumvent normal access controls.

Retention is the other side of audit. Copilot interactions are data, and data must follow your retention policies. Copilot prompts and responses stored in Exchange mailboxes and SharePoint sites are subject to the same retention rules as any other email or document. If your retention policy deletes email after 7 years, Copilot-generated email drafts will be deleted after 7 years.

The retention question becomes interesting when Copilot generates content that references multiple source documents with different retention periods. A summary pulling from a 2-year retention document and a 10-year retention document inherits the longer period – 10 years. This follows the same principle as retention label conflicts: Purview applies the longest applicable retention period. Verify this is working by checking the retention status on Copilot-generated documents in Content Explorer. If the expected retention label is not applied, your label inheritance or auto-labeling configuration may need adjustment.