Microsoft Purview DLP to Halt Copilot Web Searches for Sensitive Prompts in July 2026

Microsoft will begin blocking Microsoft 365 Copilot from using web search when a user’s prompt contains sensitive data, adding a new layer of data loss prevention (DLP) control expected to reach general availability in July 2026. The feature, tracked as Roadmap ID 565870, was added to the Microsoft 365 roadmap on June 26, 2026, and gives enterprise administrators the ability to configure Microsoft Purview DLP policies that specifically prevent Copilot and Copilot Chat from sending potentially confidential information to Bing in real time.

The control arrives amid growing organizational anxiety over how generative AI tools handle corporate data. While Copilot already taps into Microsoft Graph data to ground its answers, its ability to retrieve live web results has raised concerns that sensitive prompts—containing financial figures, patient health information, or trade secrets—could leak out through search engine query logs. Microsoft Purview’s new capability aims to close that gap automatically.

How the Block Works

Under the hood, Microsoft Purview DLP inspects the text a user types into the Copilot prompt box before any web search is executed. The DLP engine applies the organization’s existing sensitive information types—such as credit card numbers, social security numbers, medical conditions, or custom classifiers defined by the company—to detect risky content. If the prompt triggers a DLP rule configured to block web search, Copilot immediately disables its web grounding capability for that specific interaction.

Crucially, the feature does not necessarily prevent Copilot from answering altogether. If the prompt can still be fulfilled using internal Microsoft 365 data—files in SharePoint, emails in Exchange, meeting summaries from Teams—Copilot may proceed with an answer based solely on those organizational sources. But when no internal grounding data exists, the user sees a notice that the request cannot be completed due to policy restrictions.

This differs from existing Purview DLP controls for Copilot that block the entire prompt from being submitted if it contains sensitive data. Those policies function upstream, stopping the user before Copilot ever processes the request. The new web-search block works downstream, allowing the prompt to be evaluated against internal data while cutting off the external web connection. Administrators can choose which approach best fits their risk tolerance.

The DLP engine classifies data using over 300 pre-defined sensitive information types, including widely recognized patterns for financial, medical, and personally identifiable information. Organizations can also create custom sensitive information types using Exact Data Match (EDM) to detect proprietary data strings such as project codes, client IDs, or internal classifications. When a prompt matches any of these, the policy action fires before any outbound web request is made.

The Web Grounding Risk

Microsoft 365 Copilot’s web grounding feature—powered by Bing Search—fetches up‑to‑the‑minute information to enhance responses. For example, a user asking “What is our competitor’s latest product launch?” can receive an answer that blends internal sales data with recent news articles. But in performing that search, the user’s prompt, including any sensitive details, is sent to Bing’s servers as a search query.

Even though Microsoft has stated that it applies commercial data protection measures—such as not using prompts to train underlying models and enabling enterprise‑grade encryption—the fact that the query leaves the tenant boundary raises compliance flags for regulated industries. A healthcare administrator asking “Summarize patient Jane Doe’s SSN 123-45-6789 history and latest treatment guidelines” could inadvertently transmit protected health information (PHI) to a public search engine, violating HIPAA rules.

For organizations subject to GDPR, financial regulations, or internal data handling policies, that exposure is unacceptable. The new Purview DLP control provides a straightforward mitigation: it identifies that the prompt contains an SSN pattern and instructs Copilot to skip the web search entirely, keeping the patient’s identifier within the tenant. Web search activity associated with Copilot interactions is also logged, so even outside the DLP context, security teams can audit for accidental exposure events.

Configuration and Policy Setup

Microsoft Purview administrators will find the new control integrated into the existing DLP policy configuration workflow. To activate it, a compliance officer navigates to the Purview compliance portal, creates or edits a DLP policy targeting Microsoft 365 Copilot as the location, and then defines a rule that includes the condition “block web search.” Policies can be scoped to all Copilot users, specific groups, or security roles.

Configuring the block takes just a few steps:
- In the Purview portal, select Data loss prevention > Policies, then choose to create a custom policy.
- Name the policy, and under “Choose locations,” select Microsoft 365 Copilot (this also covers Copilot Chat).
- On the “Define policy settings” page, create a new rule. Under “Conditions,” add a content contains sensitive information type condition and select the desired classifiers.
- In the “Actions” section, choose “Block web search.” Additional actions like sending incident reports or showing policy tips can be layered on.
- The policy tip can be customized to read: “Your prompt contains information that is restricted from web search. The request will proceed with internal data only.”
- Review and deploy the policy. Use simulation mode initially to gauge impact before enforcing.

Policies can trigger on any combination of built-in or custom sensitive information types. For instance, a financial services firm might define a custom type for internal project codes that should never leave the tenant. If a prompt contains that code, the web-search block kicks in. Confidence levels and instance counts can be adjusted to reduce false positives.

Administrators can also configure policy tips to educate users. When the rule matches, a tip appears in the Copilot interface: “Your prompt contains sensitive information. Web search has been disabled for this query.” Overrides are not available by default, but organizations can choose to allow users to override the block after providing a business justification—a common capability in Purview DLP.

Policy simulation mode remains available, allowing admins to test the impact of the new control before enforcing it. The Purview DLP reports will show how many prompts triggered the web-search block, which sensitive information types were matched, and which users were affected. This data helps security teams fine‑tune the policy to balance productivity with protection.

Impact on End Users

For most employees, the new control will be invisible until a sensitive prompt is caught. At that point, instead of waiting for a web‑augmented response, Copilot either returns an answer from internal sources or displays a message that the request cannot be completed because it requires web access that has been blocked by policy.

Early adopters who tested the feature in preview have indicated that the block can feel abrupt when users are accustomed to Copilot’s full, internet‑connected capability. Microsoft recommends that organizations communicate the change and train users on what constitutes sensitive information under company policy. Some companies may choose to pair the web‑search block with existing prompt‑blocking policies for the most critical data types, ensuring a defense‑in‑depth posture.

False positives are a concern in any DLP deployment. A prompt containing a string of numbers that matches a credit card pattern could block web search unnecessarily. To manage this, Microsoft provides options to increase the matching confidence threshold or to require multiple instances of the sensitive type before triggering the block. These adjustments help reduce friction without compromising security.

A Piece of a Broader AI Governance Strategy

Microsoft has steadily expanded Purview’s coverage over Copilot since the AI assistant’s launch. Earlier milestones include DLP controls that inspect and block sensitive prompts before they are sent, audit logs that capture all Copilot interactions, and integration with Microsoft Defender for Cloud Apps to detect risky AI usage. The web‑search block is a logical extension—addressing a specific, high‑risk scenario that other controls could not handle elegantly.

The feature also aligns with the company’s broader commitment to responsible AI. Microsoft has emphasized that commercial user data is not used to train its AI models, and it provides contractual commitments around data residency and privacy. Yet those safeguards depend on data not leaving the tenant in the first place. By keeping search queries inside, Purview DLP reinforces those protections at the technical level.

Industry analysts note that similar controls will likely become table stakes for enterprise AI platforms. “As collaboration tools gain more real‑time intelligence features, the ability to intercept risky prompts before they hit the open web becomes a non‑negotiable part of a zero‑trust data strategy,” said one governance consultant. The management overhead, however, will fall to already-stretched compliance teams that must continuously update sensitive information types to match evolving business data.

Licensing and Availability

The web‑search DLP control is expected to be available to organizations with Microsoft 365 E5, Microsoft 365 E5 Compliance, or an equivalent Microsoft Purview license that includes DLP for Microsoft 365 Copilot. Organizations on lower‑tier plans, such as Business Premium or E3, may need to purchase the standalone Purview DLP add‑on. The table below summarizes the licensing prerequisites.

When it launches in July 2026, the feature will be turned off by default, meaning administrators must actively configure a DLP policy to enable the blocking behavior. Microsoft has not yet announced whether the control will be accessible via Graph API for automated policy management, though such support is typical for Purview features. The roadmap entry does not indicate any geographic or cloud‑sovereignty delays, implying worldwide availability for commercial cloud customers.

What’s Next for Copilot Data Security

Looking ahead, Microsoft’s roadmap suggests that DLP capabilities will continue to deepen. Teased features include more granular controls that classify not just the prompt but the generated response, integration with information protection labels so that Copilot respects the sensitivity label of source documents, and the ability to apply encryption or rights management protections to Copilot outputs.

The web‑search block may also evolve to support dynamic risk scoring, where prompts with multiple moderate indicators are blocked while single‑flag prompts are allowed with a warning. Machine learning models trained on tenant‑specific data could eventually predict the likelihood that a prompt contains confidential information, even without explicit pattern matching.

For now, the July 2026 release represents a critical checkpoint for organizations that have hesitated to roll out Copilot due to data leakage fears. With the ability to surgically remove web grounding from sensitive interactions, compliance teams gain a powerful veto without sacrificing the productivity benefits of the AI assistant.

Administrators preparing for the rollout should inventory their sensitive information types, review their current DLP policies, and run simulations to understand the impact on workflows. The feature’s success will depend not just on the technology but on clear communication between security teams and the employees who use Copilot daily.