Microsoft shipped a long-awaited governance tool for Microsoft 365 Copilot that lets administrators block specific websites from shaping AI-generated answers. The domain exclusion feature, listed under Roadmap ID 503144 and now generally available worldwide, gives organizations a middle ground between shutting off web search entirely and letting Copilot roam the open internet without restrictions.
What actually changed
Until now, admins could only flip a binary switch: web grounding on or off. Web grounding lets Copilot supplement its built-in knowledge with current public information from Bing, which is critical for questions about recent events, new regulations, or updated product documentation. Turning it off closes a potential risk vector, but it also starves the assistant of timely data and can push employees to less governable consumer AI tools.
The new control adds a denylist. Administrators can specify a limited set of domains that Copilot must ignore when pulling web content into a response. Those sites are excluded at retrieval time—not merely hidden after the fact—so their material cannot influence the generated text. The capability applies to Microsoft 365 Copilot and Copilot Chat across desktop and web platforms in the Standard Multi-Tenant cloud, with general availability pegged to June 2026.
Crucially, domain exclusion is not a web filter. It does not prevent users from visiting a blocked site in Edge or clicking a link in an email. It only governs whether Copilot can treat that domain as a source. Also, information from an excluded site may still appear if it is syndicated or quoted by an unblocked domain. Microsoft has not disclosed the exact per-tenant limit for the denylist, but the roadmap describes it as a “limited set.” Early operational details suggest PowerShell-based management as the initial administrative path.
What it means for you
For IT administrators
The feature fills a glaring gap in the Copilot control plane. Instead of inheriting the full risks of open web search or the productivity loss of blocking it entirely, you can now surgically remove sources that are known to host malware, outdated documentation, persistent misinformation, or content that violates internal policies. Each exclusion becomes an auditable record that demonstrates deliberate governance—something regulators and compliance teams increasingly demand. You should still pair this with Microsoft Purview policies to prevent sensitive prompts from triggering web queries at all, and with existing permissions controls for internal grounding sources like SharePoint and OneDrive.
For security and compliance teams
Domain exclusion offers a rapid containment option. If threat intelligence identifies a new site serving poisoned content designed to manipulate AI agents, you can block it without disabling web grounding org-wide. But it is not a cure-all. Malicious actors can pivot to new domains or seed harmful content on legitimate platforms. You still need layered defenses: safe browsing, prompt-injection detection, user education, and continuous monitoring of Copilot telemetry for suspicious grounding patterns. The feature also does not address internal data risks; sensitivity labels and data loss prevention remain essential.
For everyday users
The change should be invisible. Users won’t see alerts that a site was blocked; Copilot simply won’t cite it. That consistency is good, but it can also cause confusion if an expected authority suddenly disappears from answers. Organizations should communicate broadly when blocking a well-known source, especially one that frequently appears in research workflows. And everyone must remember: excluding a domain does not automatically make the remaining web sources trustworthy. Users still need to verify critical output—especially for legal, financial, medical, or safety decisions.
How we got here
Enterprise AI governance has evolved from a checkbox (“Is Copilot available?”) to a layered policy problem. When Microsoft 365 Copilot launched, web grounding was a headline differentiator: it made answers more relevant and current. But regulated industries—banking, healthcare, government—immediately asked for controls. The initial “Allow web search in Copilot” policy, introduced via cloud policy, let admins enable or disable the feature per user group. That binary approach forced tough trade-offs.
Customers reported that blocking all web grounding led to knowledge workers leaning on unmanaged browser searches or personal AI tools, creating shadow IT risks. Microsoft’s Copilot Control System, announced alongside Copilot, promised finer knobs. Domain exclusion is one of the first to land. It aligns with a broader industry trend: enterprise AI platforms are being judged less on raw model capability and more on how precisely they can be governed. Google, OpenAI, and others face the same pressure to deliver source-level controls.
This feature also addresses a specific pain point: outdated or unofficial corporate sites. Many organizations struggle with legacy domains—old support portals, acquired-brand pages, abandoned campaign microsites—that rank well in search and contaminate Copilot’s output. Blocking those sites directly can improve answer quality while directing the AI to authoritative sources.
What to do now
1. Draft a policy, not just a list
Before typing domains into a configuration screen, define the criteria for exclusion. A good policy might cover domains that:
- Are known to distribute malware, phishing content, or hostile AI prompts.
- Provide repeatedly false information relevant to your business.
- Host obsolete documentation that contradicts a current authoritative source.
- Are prohibited by legal, regulatory, or contractual obligations.
- Impersonate your organization or misrepresent your products.
- Have been identified in a formal incident review as a recurring problem.
2. Assign cross-functional ownership
The exclusion list isn’t purely an IT concern. Security teams should flag malicious domains. Legal should review intellectual property and compliance implications. Communications may need to block old corporate sites. Business unit leads understand which external sources are critical for their workflows. One group—likely a governance committee—should maintain the master register with approval dates, review cycles, and documented justifications.
3. Test before broad enforcement
Validate exclusions in a pilot scope if your tooling supports staged rollouts. Capture baseline prompts that currently draw from the target domain, apply the block, and rerun the prompts. Check that citations from the excluded site disappear and that alternative sources are adequate. Pay attention to subdomains, redirects, and syndicated content; a single test is not permanent proof. Plan for periodic revalidation because search results change over time.
4. Integrate with other Copilot controls
Domain exclusion is one piece of a broader governance stack. Combine it with:
- The “Allow web search” policy to control who can use web grounding at all.
- Microsoft Purview policies to block web queries when sensitive information is detected in a prompt.
- SharePoint and OneDrive controls to govern internal grounding sources.
- Copilot audit logs and activity explorers to monitor grounding behavior and verify that exclusions are working.
5. Communicate and educate
Tell users what the policy does—perhaps without revealing every blocked domain—and remind them that Copilot’s output still requires human judgement. If an exclusion causes a noticeable drop in answer quality for a critical workflow, create a path for employees to request review, and maintain an appeal process that forces evidence-based decisions.
Outlook
Domain exclusion is likely an intermediate step. Many organizations will eventually demand allowlisting—permitting Copilot to ground only from approved authorities. That model offers tighter control but can quickly become unmanageable and brittle. Microsoft may introduce category-based controls (e.g., block newly registered domains or known misinformation sites) using classification intelligence. Administrators should also watch for agent-specific grounding policies: an autonomous agent that drafts client communications will need stricter source boundaries than a general chat assistant. Finally, richer audit events that show exactly when a domain policy blocked retrieval would help compliance teams validate enforcement without manual testing. For now, the new denylist is a pragmatic tool that closes a governance gap—and a signal that enterprise AI management is growing up.