Nearly every Copilot for Microsoft 365 rollout I'm involved in begins with the same worry: what happens if Copilot pulls up sensitive or wrongly shared SharePoint content? That concern is justified, given how far SharePoint has sprawled in many environments over the years. In March 2024 Microsoft answered with a pragmatic, if limited, tool called Restricted SharePoint Search. It lets admins restrict Microsoft 365 search and Copilot grounding to a curated list of up to 100 trusted SharePoint sites, plus content users own themselves or have recently interacted with.

Restricted SharePoint Search filters results without touching permissions

This is the part people most often get wrong. Restricted SharePoint Search does not change actual permissions. Users can still reach any file or SharePoint site they already have rights to, regardless of whether it's on the allowed list. What changes is that global search and Copilot only surface content from the explicitly allowed sites, plus anything the user owns or recently touched. If someone has worked on a document before, it will keep showing up in their search results even when its site isn't on the list.

You configure it with SharePoint Online PowerShell. Set-SPOTenantRestrictedSearchMode -Enabled $true enables it for the whole tenant, and Add-SPOTenantRestrictedSearchAllowedList is how you maintain the list of permitted sites. Microsoft's documentation is clear and covers the gotchas around inheritance and edge cases (overview, configuration details).

Before you turn it on, think hard about which sites belong on the list, and decide how you'll keep it current as the environment changes. Make the list too short and users soon notice that results from sites they depend on have disappeared. Make it too broad and you lose the protection you enabled the feature for in the first place.

Restricted Search shields a pilot but leaves the underlying risk in place

In my experience, Restricted SharePoint Search works best as a temporary shield while you clean up oversharing and permissions across your SharePoint estate. Any large environment has legacy sites and old sharing links, which means risky access is hiding somewhere. While that cleanup is underway, limiting search and Copilot to a small set of vetted sites lets you get a Copilot pilot going instead of putting adoption on hold entirely.

It is not, however, a substitute for cleaning up permissions properly. The underlying access stays the same, and anything a user (or an attacker) can see is still reachable through direct links. Restricted SharePoint Search hides the risk from Copilot and search. It doesn't remove it. If you're preparing for a wider Copilot rollout, your main effort belongs in fixing permissions and oversharing. I covered practical next steps in an earlier post on Copilot for Microsoft 365 tenant readiness.

The allowed list decides what search and Copilot can surface

To show exactly how Restricted SharePoint Search fits together with Microsoft 365 search and Copilot, I drew this simple Mermaid diagram:

flowchart TD
    U["User"] --> S["SharePoint Search"]
    S --> F["Shared Content (Permissions)"]
    S --> L["Sites on Allowed List"]
    S --> O["Owned/Recent Content"]
    S -.-> X["Not on Allowed List"]
    X -.->|"Not Searchable"| S

Figure: Simplified view of Restricted SharePoint Search. Search and Copilot see the allowed list and user-owned content, never everything.

If you want more detail, Microsoft's documentation on architecture and data protection is worth reading. It makes clear that Restricted SharePoint Search is a filter and not a security boundary.

The feature brings practical benefits along with some real pitfalls

Here's what I've seen in actual projects. Users get confused when search suddenly "misses" content they technically have access to, particularly Teams or project sites that aren't on the allowed list. New or renamed sites have to be added by hand, which gets tedious fast in organizations that change a lot. And the 100-site limit is easier to reach than you'd expect once you try to cover every department or larger project area. Several tenants I know have already hit it during their pilots.

Pro tip: Before enabling, export a current list of all active sites (Get-SPOSite), go through it with the business owners, and decide which sites really have to be on the allowed list. You won't get it perfect, so concentrate on what drives day-to-day work during the pilot.

For these reasons I see Restricted SharePoint Search as a tactical band-aid rather than a strategic fix.

I treat it as a temporary brake rather than a long-term policy

Restricted SharePoint Search is a good way to buy time for a safe Copilot pilot, but you can't run on it indefinitely. Leave it on too long and you end up with frustrated users, gaps in search and a false sense of security. Getting permissions and sharing right is work you can't skip. When the access cleanup is finished, turn Restricted Search off and let Copilot show what it can actually do. If you don't, you're only sweeping the mess under the rug.