Microsoft Purview DLP for Copilot web search stops sensitive prompts from being sent to external web search providers, while still letting Copilot answer from internal Microsoft 365 data. That is useful, and frankly overdue, because too many AI rollouts still treat web grounding like a harmless default.
The roadmap item says this starts rolling out globally in late June 2026. Microsoft’s documentation is more specific about what it actually does: when a prompt contains configured sensitive information types, Copilot blocks external web search as a grounding source and falls back to allowed internal Microsoft 365 data. This applies to Microsoft 365 Copilot, Copilot Chat, and agents built in Copilot Studio that are published to Microsoft 365 Copilot.
What does this control actually do?
This is not a general "make Copilot safe" switch. It is a targeted DLP control for one exfiltration path: external web search.
In Purview, admins can create a DLP policy for the Microsoft 365 Copilot and Copilot Chat location, detect sensitive information types, and apply the action Prevent Copilot from processing content and then Performing Web Searches.
Policy location: Microsoft 365 Copilot and Copilot Chat
Condition: Content contains > Sensitive information types
Action: Prevent Copilot from processing content > Performing Web Searches
When the rule matches, Copilot does not send that prompt-derived query to external web services. It still responds using permitted internal data sources.
That matters because Microsoft also documents that web search queries derived from prompts can be shown to users in citations and logged for admin investigation. If your users can accidentally paste regulated data into a prompt, blocking the external web hop is a sensible baseline.
Why this is good, and why it is not enough
My view: this is a good control, but it is easy to oversell.
The good part is obvious. You reduce one class of leakage without having to ban Copilot outright. For teams building Microsoft Copilot and AI agents, this is the sort of least-privilege control you want: don’t give the agent a wider data egress path than it needs.
But this is only one layer.
Microsoft’s own Purview docs describe separate controls for:
- blocking sensitive prompts entirely in preview
- restricting sensitive files and emails from processing
- blocking external email as grounding data in preview
So if an organization reads this roadmap item and concludes "Copilot is now covered," that is the wrong takeaway. It covers one route, not the whole estate. If you built custom agents, grounded them on overshared SharePoint content, or left tenant-wide defaults loose, this will not save you. That is where an AI and automation audit is usually more valuable than another optimistic enablement workshop.
The licensing and governance angle to watch
One detail worth calling out: Microsoft’s service description says Purview DLP for prompts is available to all users of M365 Copilot and Copilot Chat. That is good news because it lowers the barrier to using this specific protection.
Still, governance does not end at licensing. The real work is classification quality, custom sensitive information types where needed, simulation, exception handling, and monitoring. Bad SIT coverage means a bad control, full stop. And Microsoft explicitly notes you cannot combine "sensitive information types" and "sensitivity labels" in the same rule. You can put them in the same policy, but not the same rule. That sounds minor until someone assumes one catch-all rule exists and wonders why enforcement is inconsistent.
What I would do in practice
If you are already deploying Copilot or publishing agents into Microsoft 365 Copilot, I would treat this as a safe default and enable it early. Then verify the rest of the stack:
- classify the obvious regulated data first
- add custom SITs for internal identifiers that matter
- review web grounding alongside prompt blocking and file/email restrictions
- test Copilot Studio agents specifically, not just the main Copilot chat
- stop pretending DLP alone is your AI governance model
If you need help putting the wider control plane together across Purview, Power Platform, and custom AI workflow automation, this feature fits best as one guardrail in a broader design.
Useful? Yes. Sufficient? No. That is the right level of enthusiasm here.
