Introduction

Microsoft 365 Copilot (Copilot) grounds its responses in your organizational data—emails, files, chats—and, optionally, the public web. With web search enabled, Copilot fetches real-time information from the Bing search service to deliver richer, more current answers. But what happens when a user’s prompt contains sensitive data such as credit card numbers, passport numbers, or Social Security numbers?

That’s where a new feature in Microsoft Purview Data Loss Prevention (DLP) becomes essential: it keeps sensitive information from reaching external web search during Copilot’s query generation, preventing inadvertent data leakage while preserving the productivity benefits of AI.

At a Glance

In short: admin and user toggles decide whether Copilot can search the web; Microsoft Purview DLP decides what data may leave when it does. .

• Admin and user toggles are binary on/off controls—they aren’t aware of sensitive data.


• Prevents Copilot from using external web search as a grounding source for that prompt. It does not block the prompt itself or prevent Copilot from generating a response using permitted sources.


• It works regardless of your web search configuration,even as a safety net if web search is disabled.

The Web Search Landscape in Copilot

Before diving into the DLP  feature, it’s important to understand the web search controls already available in Copilot and how they interact with this DLP feature.

How Web Search Works in Copilot

When web search is enabled, Copilot parses user prompts and generates search queries sent to the Bing search service. These generated queries are different from the user’s original prompt—they consist of a few words informed by the prompt. Importantly:

• The user’s entire prompt is NOT sent to Bing (unless it’s very short)


• Entire Microsoft 365 files (emails, documents) are NOT included in the search query


• User and tenant identifiers are removed before queries reach Bing


• Web search queries are not used to improve Bing, create advertising profiles, or train AI models


• Queries are treated as customer confidential information

Admin Controls for Web Search

IT administrators have several options to manage web search through the “Allow web search in Copilot” policy in Cloud Policy service for Microsoft 365:

• Enabled in Microsoft 365 Copilot and Microsoft 365 Copilot Chat: Web search is available across all Copilot experiences. Users get the Web content toggle to control it personally.


• Disabled in Microsoft 365 Copilot and Microsoft 365 Copilot Chat: Web search is completely turned off. The Web content toggle is dimmed and unavailable to users.


• Disabled in Work mode; Enabled in Web mode and Copilot Chat: A hybrid approach where web search is blocked in Work mode (where organizational data is accessed) but available in Web mode and Copilot Chat.

User-Level Control: The Web Content Toggle

When the admin enables web search, users in Copilot (Work chat) have a “Web content” toggle that is ON by default. Users can turn it off to exclude web content from their Copilot responses. This toggle is NOT available in Copilot Chat.

The Gap: Why Admin Controls and User Toggles Are Not Enough

Here’s the critical question: What if your organization has web search enabled (for good reasons—better answers, real-time data, improved productivity) but a user inadvertently includes sensitive information in their prompt?

Consider these scenarios:

• A user asks Copilot: “What are the compliance requirements for processing credit card number 4532-XXXX-XXXX-1234?”


• An employee types: “Find regulations related to passport number AB1234567 for our international transfer.”


• A prompt includes a customer’s Social Security number while asking about tax filing procedures.

In each case, if web search is enabled, Copilot might generate a search query informed by the sensitive data in the prompt. Even though Copilot doesn’t send the entire prompt to Bing, the generated search query could still be influenced by or contain fragments of sensitive information.

This is the gap that DLP for external web search fills—and it works regardless of which web search configuration option your admin has chosen.

The Solution: DLP Policy to Restrict Web Search When Prompts Contain Sensitive Data

Microsoft Purview DLP allows you to create a policy that detects when a user’s prompt contains sensitive information types (SITs)—such as credit card numbers, passport numbers, Social Security numbers, or custom SITs defined by your organization—and automatically prevents Copilot from using external web search as a grounding source for that specific prompt.

How It Works

• Real-Time Detection: The DLP policy evaluates each prompt in real time, checking for configured sensitive information types before Copilot generates any web search query.


• Surgical Blocking: Only the web search component is prevented for that specific prompt. Copilot continues to generate responses using permitted internal Microsoft 365 data sources (emails, files, chats) where applicable.


• Per-Prompt Enforcement: The restriction applies only to prompts that actually contain sensitive data. The next prompt from the same user (without sensitive data) will use web search normally.


• Supports various available SIT Types: Works with Microsoft-provided SITs (credit cards, passports, SSNs, etc.) and custom SITs defined by your organization.


• Clear User Notification: Users are informed that web search was restricted for their prompt due to organizational policy, maintaining transparency.

Why This Feature Is Critical, Regardless of Your Web Search Configuration

This is the key insight that every security and compliance team must understand: The DLP policy for external web search provides a fundamentally different layer of protection than the admin toggle or user toggle for web search.

Scenario 1: Web Search Fully Enabled

With web search enabled across all Copilot experiences—the most common setup—the DLP policy acts as a safety net. Normal prompts get full web-grounded answers, but the moment a prompt contains sensitive data, web search is blocked for that prompt alone. External web grounding is prevented for that prompt when the policy detects configured sensitive content.

Scenario 2: Web Search Disabled in Work Mode, Enabled in Web Mode

Even here, users in Web mode and Copilot Chat still have web search active. The mode-level toggle is binary (on/off) and can’t tell safe prompts from sensitive ones—so if a prompt in these modes contains sensitive data, DLP adds prompt-level, data-aware protection beyond binary web-search controls..

Scenario 3: Web Search Enabled with User Toggle Available

Expecting users to toggle off web search before every sensitive prompt is unrealistic—they don’t always know when content counts as sensitive by compliance standards. The DLP policy removes that human error, detecting and blocking automatically on a per-prompt basis.

Scenario 4: Even When Web Search Is Fully Disabled

Even with web search disabled entirely, the DLP policy adds defense-in-depth. Configurations change, policies get modified, and new users join groups with different settings. If web search is ever re-enabled—intentionally or not—the policy keeps sensitive data protected.

Comparing the Controls: A Side-by-Side View

 

Key Takeaway: The admin toggle and user toggle control whether web search is available. The DLP policy controls what data can be sent when web search is available. These are complementary, not overlapping controls.

Prerequisites

Before you configure the policy, make sure you have:

• Licensing: Microsoft 365 Copilot licenses for your users, plus Microsoft Purview Data Loss Prevention (included with Microsoft 365 E5 or E5 Compliance, or an equivalent plan).


• Permissions: An account with a role that can create DLP policies for the Copilot location, e.g. Compliance Administrator or the Purview Data Security AI Admin role.


• Sensitive information types: The Microsoft-provided or custom SITs you want to detect (credit card numbers, passport numbers, SSNs, and so on) identified ahead of time.

How to Configure the DLP Policy

Follow these steps to set up the protection in Microsoft Purview:

1. Sign in to the Microsoft Purview portal (https://purview.microsoft.com).


2. Go to Data Loss Prevention > Policies and select + Create policy.


3. Select the Custom template, then Custom policy.


4. On the Locations page, set the Microsoft 365 Copilot and Copilot Chat location to On.


5. Add a rule with the “Content contains” > “Sensitive information types” condition and choose the SITs you want to detect (e.g., Credit Card Number, Passport Number, SSN, or custom SITs).


6. In the same rule, set the action to “Prevent Copilot from processing content” > “Performing Web Searches”.


7. Save and turn on the policy.

Policy Design note: Conditions based on sensitive information types and sensitivity labels must be configured in separate rules within the same policy.

Note: DLP policy changes can take up to 4-8 hours to take effect in Copilot. Deploy in simulation (test) mode first to review the impact before you enforce the policy.

Real-World Use Case: Contoso

Contoso wants employees to use Copilot for productivity and has web search enabled to provide the best possible responses. However, they don’t want sensitive customer data—such as credit card numbers or national identification numbers—to be sent to external web search when Copilot grounds responses on the web.

They configure a DLP policy targeting the Microsoft 365 Copilot and Copilot Chat location with a rule that detects their relevant SITs and sets the action to “Prevent Copilot from processing content” > “Performing Web Searches”.

Result: When a user submits a prompt containing those SITs, Copilot does not send the prompt to external web search. Copilot still returns a response grounded in internal Microsoft 365 data sources where the user has access. For all other prompts, web search works normally. Other prompts can continue to use web search, subject to applicable settings and policies

Best Practices

• Deploy the DLP web search policy alongside your existing web search admin controls for defense-in-depth.


• Include both Microsoft-provided and custom SITs relevant to your industry and data classification.


• Use simulation mode first to understand the impact before enforcing the policy.


• Combine with the “Prevent sensitive information types in prompts” DLP action for comprehensive protection (note: these must be separate rules within the same policy).


• Regularly review DLP alerts to identify patterns of sensitive data in prompts that may indicate user training needs.


• Document your layered approach: admin toggle for broad control, DLP for data-aware conditional control.

Conclusion

The “Restrict Microsoft 365 Copilot from using external web search when prompts contain sensitive data” DLP capability fills a critical gap. Admin policies and user toggles give broad on/off control over web search availability, but they can’t tell a prompt that’s safe to ground on the web from one carrying sensitive information that must never leave your Microsoft 365 boundary.

This DLP feature adds intelligent, real-time, per-prompt protection that works regardless of your web search configuration. Users keep the productivity benefits of web-grounded Copilot responses without compromising data security—a clear example of security enabling productivity rather than restricting it.

Bottom line: If your organization uses M365 Copilot with web search in any capacity, this DLP policy isn’t optional—it’s essential.

References

• DLP for Microsoft 365 Copilot, Copilot Chat and Cowork: https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about 


• Data, Privacy, and Security for Web Search in Copilot: https://learn.microsoft.com/en-us/microsoft-365/copilot/manage-public-web-access