Reducing SharePoint oversharing fixes what Copilot can reach. The next layer fixes what Copilot is allowed to do with a given prompt — in real time. That layer is Microsoft Purview Data Loss Prevention for Copilot, and it’s the most under-used control I see in early deployments.

Why a second layer at all?

If permissions were perfect, you might not need runtime controls. They never are. People mislabel files, an over-broad share slips through review, a user pastes a customer record into a prompt. DLP gives you a behavioural backstop that doesn’t depend on every permission being flawless. Think of it as the difference between who can reach the data and what the AI is permitted to do when sensitive data shows up anyway.

What Purview DLP for Copilot can actually do

Working from a sensitive information type (SIT) or a sensitivity label, DLP policies for Microsoft 365 Copilot can:

  • Block web grounding when a prompt contains configured sensitive data — so Copilot won’t send that context out to a web search.
  • Block processing of labelled content — items carrying specific sensitivity labels are excluded from Copilot grounding.
  • Constrain sensitive prompts — restrict Copilot from processing prompts that match a SIT (this capability has rolled out progressively across Copilot experiences, so confirm availability in your tenant).

The key mental model: DLP here isn’t a passive compliance report. It’s an active control on Copilot’s behaviour — what it can ground on, search, and process.

A sensible starter policy

I don’t recommend boiling the ocean on day one. A pragmatic first policy:

  1. Pick one or two high-confidence SITs that genuinely matter to you — say, a custom canary string and a well-tuned financial or PII type. Avoid noisy built-in types at first; false positives erode trust fast.
  2. Start with block web grounding on those SITs. It’s high-value and low-disruption — users rarely need Copilot to web-search their most sensitive content.
  3. Add labelled-content protection for your top one or two confidentiality labels, so your most sensitive classified material is excluded from grounding.
  4. Only then consider prompt-level blocking, and pilot it with a friendly group first — it’s the most user-visible action.

Tune before you widen scope. A guardrail that misfires constantly gets disabled; a precise one builds confidence.

Why classification has to come first

Notice that every action above keys on a SIT or a label. DLP is only as good as your classification. Unlabeled, unclassified data is invisible to these controls. That’s why I treat data classification as a prerequisite, not a parallel project — labels are the currency that runtime controls spend.

Prove it with a synthetic test

As always, validate with fake data and authorized accounts. Three quick tests:

  • Put a synthetic canary SIT in a prompt and ask Copilot to “search the web for news on this” — confirm web grounding is removed.
  • Ask Copilot to summarize a synthetic file carrying a blocked confidentiality label — confirm it can’t.
  • If prompt-blocking is enabled, paste a fake PII pattern and confirm the prompt is constrained.

The success criterion isn’t silence; it’s the specific, expected guardrail firing — web search dropped, label respected, or prompt constrained.

Where DLP fits in the bigger picture

Runtime guardrails are layer three of the phased Copilot launch: discover exposure, reduce oversharing, constrain interactions, instrument, then govern agents. They’re powerful precisely because they sit on top of clean permissions and good classification — not as a substitute for them.

Get those foundations right and Purview DLP turns Copilot from “hope the permissions hold” into “the platform actively refuses to do the risky thing.” That’s a story your risk committee will actually believe.

If you’d like help designing a DLP-for-Copilot baseline that protects without drowning users in false positives, let’s talk.