One concrete change: you can now stop Microsoft 365 Copilot from hitting external web search when a user’s prompt includes specific sensitive information types. For engineers, this adds a practical middle ground between “web search on” and “web search off” across the tenant.
What shipped and why it matters
Microsoft Purview DLP for Microsoft 365 Copilot and Copilot Chat now supports a rule action to block external web search when the prompt text matches sensitive information types (built-in or custom). In that case, Copilot skips the public web as a grounding source and still responds using allowed internal Microsoft 365 data. This reduces the chance that prompts with customer IDs, card numbers, or other SITs get sent outside the Microsoft 365 boundary via search.
This applies to Microsoft 365 Copilot; Microsoft also says it extends to agents built in Copilot Studio that are published to Microsoft 365 Copilot. I’d expect coverage here to keep evolving—agent behavior and knowledge sources have caveats elsewhere in the docs—so validate your scenarios before assuming parity.
How it works (and what it isn’t)
- Policy location: Microsoft 365 Copilot and Copilot Chat in Purview DLP.
- Condition: Content contains sensitive information types (SITs)—Microsoft-provided or your custom ones.
- Action: Prevent Copilot from processing content > Performing Web Searches.
- Effect: Per-prompt. If a prompt hits the SIT rule, Copilot won’t use external web search for that prompt; it still uses internal sources the user can access.
Useful contrast with existing controls:
| Control | Scope | Granularity | Notes |
|---|---|---|---|
| Allow web search in Copilot (Cloud Policy) | Tenant/users | Coarse | On/off or mode-based; users may have a Web content toggle in Microsoft 365 Copilot. |
| Purview DLP: Block web search on SIT match | Prompt text | Fine | Applies only when the prompt contains defined SITs; complements, doesn’t replace, the admin policy. |
A few constraints worth knowing:
- You can’t combine “sensitive info types” and “sensitivity labels” in the same DLP rule for this location; use separate rules if you need both in one policy.
- DLP evaluates the prompt text. Files uploaded into a prompt aren’t scanned by DLP; don’t assume file contents will trigger this.
- If you fully disable web search via Cloud Policy, this DLP action adds no value—it’s already off.
A minimal policy shape I’ve tested:
location: Microsoft 365 Copilot and Copilot Chat
rule:
if: contentContains.sensitiveInfoTypes [ 'U.S. Social Security Number', 'Credit Card Number', 'Your-Custom-SIT' ]
then: preventCopilot.performingWebSearch = true
Licensing nuance: DLP protections over prompts are broadly available with Microsoft 365 Copilot. Other Copilot DLP actions (like restricting processing of files/emails by sensitivity labels) require higher-tier SKUs—plan accordingly.
What this changes in practice
- Security/compliance teams get a scalpel, not a hammer: keep web grounding available for most users, while automatically removing it only when a prompt looks sensitive.
- Fewer incentives for teams to disable web search globally just to control spill risk; you can start with SITs that matter (e.g., PCI, national IDs) and iterate.
- Expect more “policy excluded some sources” messages in Copilot responses. Train users that this is by design, not a failure.
Limits and open questions
- Agents in Copilot Studio: Microsoft says coverage extends here when published to Microsoft 365 Copilot, but the fine print for agent data sources and label-based controls varies. I’d validate your specific agent flows, especially non-SharePoint knowledge sources.
- Adversarial prompts: if users paraphrase sensitive data so it dodges SIT detection, this control won’t trigger. Pair with sensitivity labels and endpoint DLP where it counts.
What I’d watch: telemetry. If you see frequent SIT-triggered blocks for common workflows, that’s a hint to tighten data handling upstream—or to add user affordances where web search isn’t actually needed.
The takeaway: enable the DLP rule for SIT-triggered web search blocking if you keep Copilot web search on. It meaningfully reduces exposure with minimal user friction, and it’s reversible if it bites legitimate use cases.