Microsoft pulls a Copilot admin feature days after rolling it out

Microsoft told IT admins they could block up to 1,000 specific websites from influencing Microsoft 365 Copilot's web-grounded answers. Days later it pulled the feature, without saying why. The reason is hiding in the design itself: a deny-list is the wrong shape for governing an LLM that reads the open web.

"Domain Exclusion" was an admin toggle for Microsoft 365 Copilot and Copilot Chat. It let a Search Administrator or Global Administrator upload a CSV of up to 1,000 external domains, then run a provided PowerShell script to make Copilot ignore those sites when generating web-grounded answers. Microsoft framed it as a governance lever: a way to "reduce the influence of unwanted or non-compliant web sources" without flipping web grounding off entirely.

The cap was the tell. One thousand domains is a lot of domains to curate in a CSV, but it is also a rounding error next to the public web. A reasonable enterprise block list fills a couple of hundred slots fast: competitor sites, legal-hold archives, leaked-credential databases, brand-lookalike phishing kits. Then someone has to keep the list current, audit the URLs for typos, and decide whether competitor.com/blog is in scope while competitor.com/press is not. The work does not stop.

Microsoft has not said why it pulled the feature. The rollback post reads in full: "Domain Exclusion for Microsoft 365 Copilot has been rolled back at this time. We understand the importance of this capability and are actively evaluating next steps." The original announcement was edited to point readers to the rollback. The Register reported the reversal as "days after touting" the feature and noted the absence of an on-the-record explanation.

That absence is the story. A web-grounded LLM does not need a bigger deny-list. It needs an allow-list.

The structural problem is in the prompt path, not the policy file. When Copilot answers a question with web grounding, it pulls a chunk of candidate pages, summarizes them, and cites them. Admins cannot realistically enumerate every source Copilot should distrust; the adversarial surface is too large and too dynamic. Asking an enterprise IT team to maintain the negative space of a model that reads the open web is asking them to do the model's most expensive job for it.

The cleaner control, and the one an enterprise admin flagged on the original announcement thread within hours, is an allow-list. "Off, but add an allow list," the commenter argued; on-by-default with a deny-list is, in their words, "backwards." Web grounding defaults off. Admins upload a CSV of trusted domains, run the same PowerShell, and Copilot is only allowed to read from that set. The maintenance burden drops to a finite, auditable list. The blast radius of a missed bad domain drops with it. Microsoft's existing public-web toggle already lets admins turn web access on or off; an allow-list would be the middle layer Domain Exclusion tried, and failed, to be.

For IT admins who had started mapping governance policy around Domain Exclusion, the practical move is to stop. Do not commit the CSV, do not bake the PowerShell step into runbooks, do not promise compliance reviewers a control the vendor does not currently ship. Watch the Microsoft 365 Copilot blog for what "actively evaluating next steps" turns into, and when Microsoft does ship the next version, ask one question: is the default deny, or is the default allow? The answer tells you who is doing the maintenance.