Before You Enable Copilot Web Search: Build a Governed Domain-Exclusion Practice

September 11, 2026

Before You Enable Copilot Web Search: Build a Governed Domain-Exclusion Practice

Microsoft has made a targeted web-grounding control available again for Microsoft Copilot and Copilot Chat. **Domain Exclusion** lets an administrator specify external domains that Copilot should not use when grounding responses in public web content—up to 1,000 domains—without forcing the organization to turn web search off entirely.

That is a meaningful operational option for businesses that want current information from the web but cannot treat every public source as equally appropriate. It also creates a practical next step for IT leaders: instead of debating whether AI search is “on” or “off,” build a small, reviewable control process around which sources should be excluded, why, and how the list will be maintained.

For organizations evaluating Microsoft Copilot, the feature is not a substitute for broader information-governance work. It is a focused control that can make a wider Copilot rollout easier to govern when it is paired with policy, testing, audit, and change management.

What Microsoft changed

Microsoft’s September 9 update says Domain Exclusion has rolled out again and is now available. The feature is not enabled by default. An administrator configures it through Microsoft’s provided PowerShell script, which supports creating an exclusion list from a CSV file, updating an existing configuration, exporting the current configuration, deleting a configuration, and generating a template CSV.

The control applies to Microsoft Copilot and Copilot Chat web-grounding scenarios. Microsoft describes it as an additional choice alongside the tenant-level control for allowing or disabling web search. In other words, an organization can continue to permit web-grounded answers while preventing Copilot from using specified external domains as grounding sources.

The distinction matters. A list of excluded domains is not the same thing as an approved-source list, a web proxy, a browser filter, or a guarantee that every answer is accurate. It is a targeted restriction on the domains Copilot can use for this particular grounding purpose.

Why this matters to a business

Web-grounded AI is useful precisely because public information changes quickly. Teams may ask Copilot to summarize market developments, compare public product information, research an industry, or prepare a first draft using recent external context. Turning web search off can reduce that usefulness.

At the same time, organizations may have legitimate reasons to prevent certain public sources from influencing AI-generated responses. Examples include sources that conflict with internal standards, sites that present a brand-safety concern, domains subject to regional or legal restrictions, unreliable content farms, or sources that a regulated team has decided should not be used for a particular workflow.

Microsoft’s current privacy and security documentation also emphasizes an important boundary: Copilot generates search queries and sends them to Bing when web information could improve a response. The full user prompt is not generally sent as-is, and Microsoft says prompts and responses remain within the Microsoft 365 service boundary under the applicable enterprise protections. However, web search has its own governance considerations, and Microsoft notes that web search query handling is outside the Microsoft Products and Services Data Protection Addendum, HIPAA compliance, and EU Data Boundary. That is exactly the kind of nuance that should be reviewed by security, privacy, and legal stakeholders before a broad rollout.

A practical governance sprint

Guava recommends treating Domain Exclusion as a short, evidence-based implementation sprint rather than a one-time settings change.

1. Define the policy objective

Start by documenting what the organization is trying to control. Is the priority brand safety, regulatory exposure, source quality, regional content, procurement policy, or a specific business workflow? Avoid starting with an enormous list assembled from intuition. A clear objective makes later review much easier.

Create a simple decision record for each proposed domain: the domain, the reason for exclusion, the owner, the date approved, the review date, and the business or policy reference supporting the decision.

2. Create a risk-tiered domain list

A useful first list can include domains that are clearly outside the organization’s source strategy, domains associated with known policy concerns, or sources that a particular regulated workflow must not use. Separate “exclude everywhere” decisions from narrower workflow guidance. Domain Exclusion is tenant-level administration; it should not be used casually to solve a problem that belongs in user training or a process-specific prompt standard.

Keep the list understandable. A domain that nobody can explain will become difficult to defend, review, or remove later. If the organization needs an approved-source strategy, manage that as a complementary process rather than implying that an exclusion list creates an allowlist.

3. Prepare the CSV under change control

Microsoft’s process uses a CSV and a PowerShell script. Store the working file in the organization’s normal configuration-management location, with access limited to the administrators responsible for Copilot policy. Use version control or another auditable change process so that the organization can answer three questions later: what changed, who approved it, and what behavior was tested afterward?

Before deployment, check for duplicate domains, inconsistent formatting, accidental subdomain omissions, and entries that could block a legitimate source unexpectedly. Have a second reviewer confirm that each entry reflects the stated policy objective.

4. Test representative prompts

Do not validate the configuration with one generic question. Build a small test set that reflects real work: market research, vendor comparison, technical troubleshooting, regulatory monitoring, and a prompt that combines internal context with a public-web question.

Record the prompt, the expected source behavior, the observed citations or source indicators, and the date of the test. Test both an excluded domain and a comparable domain that should remain available. Also verify how the user experience communicates that an administrator has restricted certain sources. The goal is not to prove that Copilot is always correct; it is to confirm that the policy behaves as intended and that users understand the result.

5. Establish an operating owner

A domain list will age. Vendors change ownership, sources change quality, policies change, and business teams discover new use cases. Assign an owner for intake and review, then define a review cadence—monthly for a fast-moving rollout or quarterly for a mature program.

Connect the process to existing Microsoft 365 governance. Microsoft’s documentation describes query logging and audit capabilities that can help administrators investigate how web search is being used. Decide which events should be reviewed, who can request a change, and how exceptions are handled. A small operating model is more valuable than a long list that nobody maintains.

What Domain Exclusion does not solve

The feature should not be presented as a general AI safety control. It does not validate every answer, replace human review, prevent users from visiting a site directly, or eliminate the need to govern internal Microsoft 365 data. It also does not turn public web content into a controlled knowledge base.

Organizations still need identity and access controls, data classification, retention and eDiscovery practices, user training, acceptable-use guidance, and clear rules for high-impact decisions. For sensitive work, users should understand when to verify facts against authoritative primary sources and when Copilot output is only a starting point.

There is also a practical distinction between Microsoft Copilot web grounding and other search experiences. Microsoft’s documentation notes that Copilot Search is a separate experience that can search across Microsoft 365 and third-party data sources. Teams should map the control to the actual Copilot experiences and licenses in use rather than assuming that one setting governs every form of search.

A sensible rollout pattern

For a first deployment, choose one business group with a clear use case and a willing administrator. Establish the policy objective, create a small exclusion list, run the CSV and PowerShell configuration through change control, and test a representative prompt set. Review the results with security, privacy, and the business owner before expanding.

Measure more than adoption. Track policy exceptions, user questions, source-quality incidents, time spent reviewing responses, and whether the control allows the organization to keep useful web grounding enabled. If the list grows rapidly, that may signal a need for a more structured knowledge or search strategy rather than an ever-larger set of exclusions.

The Guava perspective

Microsoft Copilot becomes easier to scale when governance is treated as part of the product experience—not as a document written after deployment. Domain Exclusion is a practical control for organizations that want more precision, but it works best inside a broader operating model that connects licensing, identity, security, data protection, user adoption, and measurable business outcomes.

Guava Systems helps businesses plan and manage Microsoft cloud environments with that full context in mind. If your team is deciding whether Copilot web grounding is ready for a broader rollout, a focused cloud and productivity assessment can identify the policy, identity, licensing, and operational controls to put in place first.

Sources

Editorial note: Microsoft’s product names and availability can change during the Copilot transition. Confirm the current admin-center experience and documentation before implementing a production policy.

Topics:
Read next
September 12, 2026

AI Cybersecurity for Business: What the Latest Threat Report Means for Microsoft 365

Anthropic’s September 2026 threat report puts AI misuse in focus. Here is a practical plan to review Microsoft 365 identity security, AI data handling, and incident response.