Does Microsoft 365 Copilot honor sensitivity labels for DLP?

Yes, the Purview sensitivity labels applied to documents and emails propagate into the Copilot context. Content classified as Confidential or higher is treated according to the policies attached to those classifications. The gap is that most enterprise content is not classified at the document level, and the policies fire only against the classified content. For an effective Copilot DLP posture, the underlying content classification has to be in place; otherwise the policy layer does not have signal to act on.

How does GitHub Copilot enterprise data handling differ from the consumer tier?

The enterprise tier provides contractual terms covering data handling, retention, and training opt-out that the consumer tier does not. The data still moves from the developer's IDE to GitHub's services and to the underlying model. The enterprise terms shift the contractual exposure. They do not change the architectural fact of the data movement. Source code with sensitive IP, customer data in test fixtures, or hardcoded credentials in source are still moving to the model regardless of tier. The classification layer at the IDE or the gateway is the architectural answer.

What about Copilot integrations into third-party vendor SaaS?

Salesforce Einstein Copilot, Slack AI's Copilot features, Notion AI's Copilot-style integrations, and the growing list of vendor SaaS tools with AI features each have their own data path. The vendor's contractual terms cover their data handling. The deploying organization is downstream of those terms. For DLP purposes, the same question applies: does the vendor route through an OpenAI-compatible API the organization can proxy? Where the answer is yes, the gateway-level enforcement is available. Where the answer is no, the organization is dependent on the vendor's controls.

Can content-aware policy decisions at the Copilot layer block a request before the model call?

For the model call surfaces the deploying organization controls (custom Copilots, proxied GitHub Copilot, embedded Copilot features routed through controllable endpoints), yes. The pre-flight classification and policy decision happens before the model call. For the standard Microsoft 365 Copilot surface, the architectural option is to influence what Copilot has access to in the first place (through Purview classification and access policies) rather than to block the model call at the wire. The two patterns reach the same policy outcome through different mechanisms.

Copilot DLP: Inspecting What Microsoft Copilot Sends to the Model

Microsoft Copilot sits inside the Microsoft 365 surface where the user's confidential email, calendar, document, and Teams content is the default working set. GitHub Copilot sits inside the developer's working source repository. The other members of the Copilot family follow the same pattern: the model has access to the same content the user has access to, by design. The data movement question is what the Copilot product sends to the model from that working set when the user asks Copilot a question, and what the enforcement layer can do about the content that should not have left the boundary.

Copilot DLP is the practice of detecting and preventing the prompt-content movement at the AI request layer. The traditional DLP stack at the email gateway, the endpoint agent, and the network egress catches a subset of the data movement and misses the prompt content because it operates at a different layer. The Microsoft-native Purview controls catch a subset of the surface and leave open the cases where the Copilot product is operating against data the controls do not classify or the cases where embedded Copilot features in other vendors' tools move similar content.

I want to walk through where Copilot DLP needs to operate, what classifiers matter, and how the per-request audit record satisfies the regulatory obligation.

What Copilot actually sends

A Microsoft 365 Copilot request, in its typical form, sends the user's prompt and a curated context window assembled from the user's accessible content: relevant emails, document excerpts, calendar entries, and Teams messages. The assembled context is what gives Copilot its productivity payoff. It is also what makes the data movement question non-obvious: the user did not explicitly paste the email, the document, or the Teams thread into the prompt. The Copilot product assembled the context on the user's behalf.

A GitHub Copilot request sends the surrounding source code context the developer is working in. The context is selected from the active file and the related files in the project. The model sees source. The model returns suggested code. The data movement is structural to the product's operation.

The other Copilot variants (Salesforce Einstein Copilot, Slack AI's Copilot integrations, Notion AI's variants) follow similar patterns. The product assembles context, sends it to a model, and returns output. The data movement is per-request.

Where traditional DLP falls short

The email DLP catches content moving through SMTP. Copilot does not move content through SMTP; the email content is read by Copilot and incorporated into a prompt that goes to a model API.

The endpoint DLP agent catches content being copied to the clipboard, attached to outgoing email from the user's desktop client, or written to removable media. Copilot's data movement happens in the Microsoft cloud, not on the user's endpoint. The endpoint agent does not see it.

The network DLP catches encrypted traffic by inspecting TLS at the boundary or by terminating TLS at a forward proxy. Copilot's API traffic flows from the Microsoft cloud to the Microsoft cloud (for the M365 Copilot case) or from the developer's IDE to GitHub's services (for GitHub Copilot). The corporate network DLP, configured for traditional egress, may or may not see the traffic depending on the routing.

The Microsoft-native Purview controls catch a subset of the surface. Sensitivity labels applied to documents and emails extend into the Copilot context. The DLP policies on those classifications fire. The gap is the content that is not labeled (most of it, in practice), the content that is in non-Microsoft sources accessible to the Copilot integration, and the content that flows through the new Copilot capabilities added in each quarterly release.

What Copilot DLP actually has to classify

The classification problem at the prompt layer is different from the document-level classification problem the traditional DLP was built around. The classifier sees a prompt that may include excerpts from multiple sources. The classifier has to make a per-prompt decision rather than a per-document decision.

The data classes that matter for Copilot DLP in regulated environments are the ones the organization's policy names. PII for any organization. PHI for healthcare. MNPI for financial services. CUI for federal contractors. Source code with IP indicators for engineering organizations. Customer account data for B2B SaaS. Trade secrets and process recipes for manufacturing.

The classifiers run on the prompt content as it leaves the Copilot product surface for the model API. The classification result drives the policy decision: allow, redact the restricted content and proceed, or block the request.

The identity binding question

The Copilot products run under the user's identity. The Microsoft 365 Copilot uses the user's Azure AD identity. The GitHub Copilot uses the user's GitHub identity, which can be federated to the corporate IdP. The identity is present at the product level.

The identity binding for DLP purposes is whether the identity propagates through the AI request to the policy enforcement layer. The Microsoft Copilot's API calls to the model are authenticated against the Microsoft cloud, not against the deploying organization's IdP. The organization sees the action at the audit-log level but does not directly authorize the model call.

For Copilot deployments that route through the deploying organization's API surface (which is increasingly the pattern for custom Copilots and the Microsoft Copilot Studio extensions), the identity binding can be configured. The custom Copilot's calls to internal services and to model APIs can route through the organization's enforcement layer.

For the standard Microsoft 365 Copilot, the model calls happen inside the Microsoft cloud and the organization's enforcement layer cannot intercept them directly. The DLP play in that case is content pre-flight: classify the data before Copilot has access, and apply Purview-side policy to the data classifications. The model-API-level enforcement is not available for the standard product.

For GitHub Copilot, the developer-side integration can route through a proxy in some deployment configurations. The architectural option exists.

The audit record question

The audit record needs to capture, for each Copilot request the enforcement layer sees, the user identity, the prompt classification, the policy applied, the decision, and the timestamp. The record is independent of the Copilot product's own logs.

For the Microsoft 365 Copilot case where the model call is inside the Microsoft cloud, the deploying organization receives audit data from Purview. The Purview audit data is what the organization has. The gap is that the audit data is under Microsoft's control and the deploying organization is downstream of it.

For the custom Copilot and the GitHub Copilot cases where the calls route through the organization's enforcement layer, the per-decision audit record is produced by the layer the deploying organization controls. The EU AI Act Article 12 disclosure obligation is satisfied by the records under the deployer's control.

DeepInspect

For the Copilot deployments where the AI request layer can be intercepted (custom Copilots, Copilot Studio extensions, GitHub Copilot with proxied routing, embedded Copilot-style features in vendor SaaS that route through OpenAI-compatible APIs), DeepInspect sits at the request boundary as a stateless proxy between the Copilot product and the model. Every request is classified, evaluated against policy, and recorded. The audit record is under the deployer's control.

For the standard Microsoft 365 Copilot where the model call is inside Microsoft's cloud, the DeepInspect play is at the data-pre-flight layer in conjunction with Purview policies for content classification. The architectural option for direct request-layer enforcement is not available for that specific product. The organization's enforcement of the AI usage policy on the Copilot surface depends on the content-classification layer.

The general pattern is that the Copilot DLP architecture has to match where the model call is reachable. For the cases where the deploying organization controls the request path, the enforcement layer produces per-request evidence. For the cases where the cloud vendor controls the path, the enforcement falls to the cloud vendor's controls and the deployer is downstream of the audit data.

If your Copilot deployment is the customizable or proxyable kind and the enforcement layer is unbuilt, the architectural primitive is the same as for any other AI deployment. Book a demo today.

If the workflow is a high-risk classification under Annex III (HR, credit scoring, education access, biometrics, critical infrastructure, law enforcement, border control, justice), Article 12 logging applies regardless of whether the AI is delivered through Copilot or through any other product. The deploying organization is the deployer and inherits the obligation. The question of whether the deployer can satisfy it depends on whether the audit record under the deployer's control is available. For workflows where the model call is inside the Microsoft cloud, the deployer's audit data is the Purview audit data, which the deployer should validate against the Article 12 record specification before relying on it.