Copilot DLP configuration guide

Key takeaways

• ✓Copilot queries against Microsoft 365 content, so any sensitivity label or DLP policy gap that exists in your tenant before you enable Copilot becomes a retrieval risk the moment a user starts prompting.

• ✓Microsoft Purview is the right control plane for Copilot DLP, but it only protects what it can see: unlabelled files, ungoverned SharePoint sites, and overly permissive sharing settings all create blind spots.

• ✓Sensitivity labels need to be applied consistently and broadly before Copilot goes live, not retrospectively. Retroactive labelling is possible but operationally painful.

• ✓The most common configuration mistakes are not technical failures but policy gaps: missing DLP rules for Copilot interaction data, default retention settings left unchanged, and no audit logging enabled for Copilot activity.

• ✓Training your team to understand what Copilot can and cannot surface is as important as the technical controls. Guardrails that users do not understand tend to get worked around.

Why does Copilot DLP configuration matter more than standard DLP?

Traditional DLP (data loss prevention) was built around a specific threat model: a user opens a file, copies content, and tries to send it somewhere it should not go. The policy intercepts the action at the boundary, whether that is an email gateway, a USB port, or a file upload. That model assumes a human is doing the moving.

Copilot changes the threat model entirely.

When a user prompts Copilot for Business in Microsoft 365, the AI does not just retrieve a single document. It can synthesise content across SharePoint sites, Teams conversations, OneDrive files, emails, and meeting transcripts, then return a coherent summary in a single response. The user never opened those files. They may not even know they had access to them. Standard DLP policies were not written for that flow, and many organisations that ran thorough DLP reviews before rolling out Copilot discovered their policies had significant blind spots.

The access problem Copilot exposes

Copilot respects Microsoft 365 permission boundaries, but it does not correct over-permissioned environments. If a user has read access to a sensitive SharePoint library they rarely visit, Copilot will surface content from it. Over-permissioning is a pre-existing problem that Copilot makes visible and exploitable at scale.

There is also the synthesis risk. A single document marked Confidential might not contain anything damaging on its own. But Copilot can draw from ten documents simultaneously, combining fragments that, together, form something far more sensitive than any one source. Classic DLP scans content at the point of transmission; it was never designed to assess the aggregated output of a generative AI query.

The other dimension is volume and invisibility. A determined insider might access dozens of sensitive documents in a day; that activity generates audit trails and may trigger anomaly detection. A user asking Copilot a broad question can pull equivalent information in seconds, with no unusual file-access pattern to flag. The exposure is real, but the signal traditional DLP relies on is absent.

None of this means Copilot is unsafe to deploy. It means the configuration work is different in character from what most DLP projects have covered before. Getting copilot DLP configuration right requires understanding exactly how Purview policies interact with the Copilot query pipeline, which is where most teams need to start.

How does Microsoft Purview DLP apply to Copilot?

Microsoft Purview is the compliance and data governance layer that sits underneath Microsoft 365. When you configure DLP (Data Loss Prevention) policies there, you are setting rules that control how sensitive information can be moved, shared, or surfaced across the Microsoft 365 ecosystem. Copilot operates inside that ecosystem, which means Purview policies can, in principle, govern what Copilot does with labelled content.

The mechanism works in two directions.

Inbound: what Copilot is allowed to retrieve. When a user prompts Copilot to summarise a document, pull data from SharePoint, or draft an email based on existing files, Copilot queries the Microsoft Graph, which is the API layer connecting all of a user's accessible Microsoft 365 content. If a file carries a sensitivity label such as "Confidential" or "Highly Confidential", and your DLP policy restricts that label's content from being surfaced in certain contexts, Purview can block or limit what Copilot returns. The user may receive a partial response, a redacted response, or a notification that the content could not be included.

Outbound: what Copilot is allowed to generate. DLP policies can also scan the text that Copilot produces before it reaches the user or is stored. If a generated response contains a pattern that matches a sensitive information type, such as a tax file number, a credit card number, or content that Purview classifies as matching a trainable classifier, a policy can block that output, generate an audit log entry, or trigger an alert.

Where sensitivity labels fit in

Sensitivity labels are the linchpin. Without them, Purview cannot reliably distinguish a confidential board paper from a public FAQ. Labels assigned in Microsoft Information Protection carry metadata that travels with the file. Purview reads that metadata when evaluating whether a DLP rule applies.

For Copilot specifically, labels matter at the point of retrieval. If a file has never been labelled, Copilot treats it as it would any accessible document: it will retrieve and summarise it if the user has permission. A DLP policy scoped to sensitivity labels cannot protect content that has no label. This is why a labelling programme must precede, or run in parallel with, any Copilot rollout. The sequence matters more than most deployment guides acknowledge.

How policy scoping works for Copilot

In the Purview compliance portal, DLP policies can be scoped to specific workloads. Microsoft has extended this to cover "Microsoft Copilot experiences", which appears as a policy location alongside Exchange, SharePoint, Teams, and the others. Selecting this location tells Purview to apply the policy to Copilot prompt and response activity, not just to file transfers or email.

Scoping is not automatic

Adding a DLP policy for SharePoint does not automatically extend that policy to Copilot interactions. You need to explicitly include Copilot as a policy location, or create a separate policy scoped to it. Many organisations discover this gap only after deployment.

Within a Copilot-scoped policy, you can define rules based on sensitive information types, sensitivity label conditions, or trainable classifiers. You can also set the action: block the response, allow it with an override and audit log, or notify the user with a policy tip. The right action depends on the risk tolerance and the use case. A legal team working with privileged documents may warrant a hard block. A sales team working with customer data might be better served by an audit-and-alert approach that surfaces compliance issues without disrupting workflow entirely.

One practical constraint worth knowing: Copilot interactions in the Microsoft 365 Chat experience (the cross-application chat surface) and Copilot embedded within specific apps like Word or Teams can behave differently depending on how policies are scoped. Testing policies against each surface before broad rollout is not optional, it is the only way to confirm the policy is doing what you think it is.

For a broader view of where AI tools create data exposure risk beyond DLP policy gaps, the data leakage through AI tools article covers seven scenarios that Purview alone will not catch.

Which sensitivity labels should you configure before enabling Copilot?

Sensitivity labels are the single most important prerequisite for a safe Copilot deployment. Without them, Purview DLP has no reliable way to distinguish a routine SharePoint document from a file containing executive salary data or M&A terms. Copilot will treat both identically, and so will the permissions it inherits.

The practical starting point is a label taxonomy that reflects how your organisation actually classifies information, not a taxonomy built to satisfy a compliance checklist. Most Australian enterprises need four to six labels at most. Common tiers look something like this:

The specific label names matter less than consistency. If your legal team calls their documents "Attorney-Client Privileged" and IT calls the same tier "Restricted", Purview cannot apply a single policy to both. Resolve taxonomy disagreements before you configure anything in Copilot.

Why auto-labelling matters more in a Copilot environment

Manual labelling relies on users making the right call at the moment they save a file. That has always been unreliable. In a Copilot deployment, the risk compounds because Copilot can surface content from sources the user never directly opened, including SharePoint sites they have access to but rarely visit.

Auto-labelling policies in Microsoft Purview scan content at rest and in transit, applying labels based on sensitive information types (credit card numbers, Tax File Numbers, Australian Business Numbers, health identifiers) and trainable classifiers (financial reports, HR records, legal documents). Configure simulation mode first, review the results against a sample of real documents, and adjust confidence thresholds before switching to enforce mode. Rushing straight to enforcement is a common mistake that results in mislabelled documents and user complaints that erode trust in the whole programme.

The label gap Copilot exposes

Organisations often discover that 30 to 60 percent of their SharePoint content carries no sensitivity label at all. Copilot makes this gap dangerous, because unlabelled content is treated as General by default and becomes fully accessible to any licensed user. Audit your label coverage before you enable Copilot at scale.

Which content repositories need labels before go-live

Not every data source needs to be fully labelled on day one, but some carry disproportionate risk:

• SharePoint Online and OneDrive are Copilot's primary retrieval sources. Any site containing contracts, financial models, HR data, or client information must have coverage in place before users are licensed.

• Exchange Online is scanned when Copilot drafts emails or summarises threads. Emails do not always carry labels, and auto-labelling policies for email require separate configuration from file-based policies.

• Teams chat and channel messages are surfaced by Copilot in meeting recaps and conversation summaries. Messages rarely carry explicit labels, so DLP policies here rely on content inspection rather than label inheritance.

• Microsoft 365 Groups and Planner are lower priority for most organisations, but any Group used to coordinate sensitive projects should carry a container label that restricts external sharing before Copilot is enabled.

The practical sequencing is to complete SharePoint and Exchange coverage first, validate label accuracy across a representative document sample, then extend to Teams and Groups. Trying to label everything simultaneously tends to produce poor accuracy and slow the whole rollout. This kind of phased approach aligns with the change management thinking covered in our guide to AI rollouts.

How do you configure DLP policies specifically for Copilot interactions?

Configuring DLP for Copilot is done through the Microsoft Purview compliance portal. The key difference from a standard DLP policy is that you explicitly scope the policy to Microsoft 365 Copilot as a location, which covers both what users send as prompts and what Copilot returns as responses.

Here is the practical sequence.

Step 1: Create a new DLP policy scoped to Copilot

In the Purview compliance portal, navigate to Data loss prevention > Policies > Create policy. You can start from a template or build a custom policy. When you reach the "Locations" step, look for Microsoft 365 Copilot (preview) in the location list and enable it. Leave other locations enabled or disabled based on your existing policy architecture; this location targets the Copilot interaction layer specifically.

Scope Copilot as a distinct location

Adding Microsoft 365 Copilot as a location in Purview means DLP rules apply to the prompt-and-response exchange, not just to the underlying documents. These are different enforcement points and both matter.

Step 2: Define your sensitive information types and label conditions

Your policy rules should reference the same sensitive information types (SITs) and sensitivity labels you have already deployed. Common conditions for Australian enterprise environments include:

• Australian Tax File Numbers (a built-in SIT in Purview)

• Credit card numbers and bank account details

• Any document labelled Confidential or above

If a user prompts Copilot in a way that would cause it to surface content matching these conditions, the policy intercepts the response before it is displayed.

Step 3: Set the action to block or warn

For each rule you have two main enforcement options.

Start with audit only for two to four weeks before switching to block rules. This gives you a realistic picture of how often staff are inadvertently surfacing sensitive content, and avoids disrupting legitimate workflows on day one.

Step 4: Configure policy tips

Policy tips are the brief in-product messages that tell a user why their prompt or Copilot's response has been restricted. Write these in plain language specific to the scenario. "This response has been blocked because it contains information classified as Confidential. Contact your IT help desk if you need access." is more useful than a generic compliance message. Clear policy tips reduce help-desk volume and reinforce the behaviour you want.

Step 5: Enable audit logging and review it

Every Copilot interaction subject to a DLP rule should generate an audit event. Confirm that Microsoft 365 audit logging is turned on for your tenant (it is on by default for most M365 plans, but worth verifying). DLP matches surface in the Activity explorer inside Purview, where you can filter by location, rule, and user. Set a recurring review cadence, weekly during initial rollout, monthly once steady state is reached, and feed findings into your broader AI adoption measurement process.

This audit trail also provides evidence of due diligence if you are operating under the Australian Privacy Act or sector-specific obligations such as APRA CPS 234. Document your policy rationale alongside the logs.

A note on prompts versus responses

Purview DLP can evaluate both the prompt a user submits and the response Copilot generates. In practice, most sensitive data exposure risk sits on the response side, because Copilot is drawing on content the user may not have consciously thought about when writing their prompt. That said, prompt-side controls matter too, particularly where users might paste classified content into a prompt to ask Copilot to summarise or reformat it. Configure rules for both directions and review your audit logs to see which direction generates more matches in your environment. For more on data leakage scenarios specific to AI tools, that article covers the patterns most commonly missed before a Copilot rollout.

What are the common configuration mistakes that create data exposure?

Most Copilot data incidents do not happen because DLP policies were absent. They happen because the policies were incomplete, tested against the wrong scenarios, or applied to a tenant that had never been properly cleaned up. These are the gaps that matter.

Overpermissioned SharePoint is the silent risk

Copilot surfaces content based on what the user can access, not what they typically access day-to-day. If your SharePoint environment has broad "Everyone" or "Everyone except external users" permissions on sensitive libraries, Copilot will treat all of that as fair game for a response. A staff member asking about executive remuneration or an upcoming acquisition could receive accurate, cited results from a document they had technical access to but were never meant to read.

Fixing this is unglamorous work. It means auditing SharePoint permissions before you enable Copilot broadly, not after your first incident. Start with your highest-classification content and work down. Overpermissioned sites are almost always legacy configurations that nobody got around to tightening.

Unlabelled legacy content falls outside every DLP rule

Sensitivity labels are the foundation of Purview DLP for Copilot. If a document has no label, most DLP rules will not catch it. The problem is that the majority of enterprise tenants carry years of unlabelled content in SharePoint, OneDrive, and Exchange. Auto-labelling policies help, but they are not instant and they are not perfect. Files that do not match your classification rules stay unlabelled until someone fixes them manually or the policy catches up.

Unlabelled content is ungoverned content

Every document Copilot can read that carries no sensitivity label is a gap in your DLP policy, regardless of how carefully you built that policy. Bulk auto-labelling and a labelling deadline for new content both need to be in your rollout plan.

The practical mitigation is to run a content explorer scan in Purview before rollout, identify the volume of unlabelled items in sensitive locations, and set a remediation deadline. It is not realistic to label everything overnight, but it is realistic to label your highest-risk repositories first and restrict Copilot's access to the rest until labelling is complete.

Policy gaps between apps compound quickly

A DLP policy applied to SharePoint and OneDrive does not automatically extend to Teams messages, Exchange mailboxes, or Copilot chat transcripts. Each workload needs to be explicitly scoped. Organisations often configure solid policies for file-based content and then leave Teams chat and Copilot interactions unprotected because those workloads were added later and nobody went back to update the policy scope.

This matters more with Copilot because Copilot synthesises across workloads. A response can draw on an email thread, a SharePoint document, and a Teams conversation simultaneously. If your DLP policy covers the SharePoint document but not the email thread, the sensitive information in the email can still surface in Copilot's output without triggering any alert. Check your policy scopes explicitly: every policy should list every workload it is intended to cover, and you should be able to demonstrate that Copilot interactions are included.

See the data leakage through AI tools article for a fuller picture of how cross-workload gaps play out in practice.

Missing or misconfigured audit trails leave you blind

DLP is partly preventive and partly detective. The detective function depends entirely on audit logs being enabled, retained, and reviewed. Microsoft 365 audit logging is not on by default in all licence tiers, and even where it is enabled, the default retention period may be shorter than your compliance obligations require.

For Copilot specifically, you want to confirm that Copilot interaction events are being captured in the audit log, that your log retention matches your organisation's data governance policy (many Australian organisations need at least 12 months), and that someone is actually reviewing the alerts your DLP policies generate. A policy that fires alerts nobody reads is not a control. It is paperwork.

A common discovery during Copilot readiness assessments is that audit logging was enabled but Copilot interaction events were not included in the scope, or that alerts were routing to a shared mailbox that had not been monitored for months. Both failures mean that a policy breach can occur, go undetected, and leave no usable forensic trail.

Frequently asked questions

Does Microsoft Copilot respect existing sensitivity labels automatically?

Copilot honours sensitivity labels applied to content it accesses, but only if those labels are configured to restrict access and are consistently applied across your environment. A label with no associated policy (for example, a label that classifies but does not enforce) will not prevent Copilot from surfacing that content in a response. Before enabling Copilot broadly, audit your label taxonomy to confirm every label that should restrict access actually has a DLP or protection policy behind it, not just a classification marker.

Can Copilot retrieve content a user does not have permission to view?

No. Copilot operates within Microsoft 365 permission boundaries, so it can only retrieve content the signed-in user already has access to. The practical risk is not Copilot bypassing permissions; it is that many organisations have over-permissioned SharePoint libraries, broad "Everyone" sharing links, or stale access grants that users did not know existed. Copilot can surface all of that. The pre-deployment step that matters most is a permissions audit, not a Copilot-specific configuration.

Which Purview DLP workloads cover Copilot interactions?

Microsoft Purview DLP policies applied to Teams and SharePoint extend to Copilot interactions that touch those workloads. As of mid-2024, Microsoft also introduced specific Copilot interaction controls within the Purview compliance portal, allowing you to audit what users prompt and what Copilot returns. You need to enable audit logging for Copilot activity separately; it is not on by default in all tenants. Check your Microsoft 365 licensing tier, because interaction-level auditing requires a Purview or Microsoft 365 E5 (or equivalent add-on) entitlement.

Is DLP configuration enough, or do we also need Conditional Access policies?

DLP and Conditional Access serve different purposes and you need both. DLP governs what content can be shared or surfaced in a Copilot response. Conditional Access governs who can authenticate to Microsoft 365 and from which device or network. A user on an unmanaged personal device with no Conditional Access restriction can still authenticate, reach Copilot, and receive sensitive content in a response even if your DLP policies are correctly configured. For a fuller picture of where AI tools create exposure, the scenarios in data leakage through AI tools are worth reviewing alongside your DLP baseline.

How do we know if our DLP policies are actually working for Copilot?

Purview activity explorer and the Copilot audit log are the two places to look. Activity explorer shows you DLP policy matches, overrides, and justifications in near real time. The Copilot audit log records individual interactions, including the sensitivity of content referenced in each response. Run a two-week review after any configuration change to confirm policies are triggering as expected and that override rates are not unusually high (a high override rate usually signals policies are set too broadly or users have not been trained on why the restrictions exist). Tracking adoption and behaviour over time is also covered in the AI adoption dashboard guide.

Does your team know how to stay inside the guardrails?

DLP policies and sensitivity labels do the heavy lifting at the infrastructure level, but they only go so far. A user who does not understand why a label exists, or who dismisses a policy tip without reading it, can still cause a data incident that your controls were designed to prevent. Configuration is necessary; it is not sufficient.

This is where most Copilot rollouts hit a wall. The technical settings are in place, but staff are prompting Copilot the same way they would search Google, without thinking about what data they are pulling into the conversation or what they are about to paste into a response. The data leakage scenarios that matter most are often not sophisticated attacks; they are routine mistakes made by well-meaning people who were never shown the boundaries.

Training bridges that gap. When employees understand how Copilot interacts with the content it can see, how sensitivity labels affect what gets surfaced, and what a policy tip is actually telling them, they make better decisions in the moment. That is not a soft benefit; it directly reduces your residual risk.

Ready to build a Copilot-aware workforce?

Better People's Microsoft Copilot workshops cover responsible use alongside practical prompting, so your team understands the guardrails and stays inside them. Sessions are delivered onsite or virtually across Australia and can be scoped for half-day or full-day formats.

Explore Microsoft Copilot training →

If you are still scoping what your team actually needs, the half-day or full-day workshop guide is a good starting point. And if adoption is already lagging, it is worth reading alongside your DLP review rather than after it.