Microsoft 365 Copilot Search respects permissions and your exclusions

Over the last few months I've watched more and more tenants roll out Microsoft 365 Copilot Search, usually with the hope that it will finally pull search together across all the silos and the shadow IT. For admins, though, the real work starts right when the user rollout does. You need to know what Copilot Search actually indexes and how it handles permissions and exclusions. You also have to keep users and the compliance team happy at the same time.

Copilot Search combines Microsoft Search with the Semantic Index

Microsoft 365 Copilot Search is the AI layer behind enterprise search in the Microsoft 365 Copilot app, which used to be copilot.microsoft.com plus the Copilot panels in Teams and Outlook. It does more than keyword matching on your files. Classic Microsoft Search (Bookmarks and Acronyms included) is combined with the Semantic Index for Microsoft 365 and large language models. Licensed users get semantic, context-aware answers from emails, Teams chats, SharePoint and OneDrive. If you've set them up, connected systems come in through Copilot connectors as well. What appears in the results depends on Microsoft Graph, semantic signals and the user's permissions together. Keep in mind that Copilot Search is a separate pipeline from the old Office search bar, extended by the semantic index and whatever connectors you've configured (see Copilot semantic index: How Copilot really finds your files).

Copilot Search indexes less than many admins assume

Out of the box, Microsoft 365 Copilot Search indexes Exchange Online, SharePoint Online, OneDrive for Business and Teams chats, as long as they're eligible for the Semantic Index. A lot of admins think everything ends up in the index. It doesn't. SharePoint sites or libraries you've excluded with Restricted SharePoint Search or Restricted Content Discovery are completely invisible to Copilot Search (more detail in Restricted SharePoint Search: Copilot pilots done right and Restricted content discovery: Keep sites out of Copilot search).

With Copilot connectors you can add other business apps and third-party sources, but only do it if your governance is solid. Each connector brings another set of permissions you have to map and monitor, and a mistake there can leak data. For external data to show up, the source system's access controls and the Microsoft 365 permissions both have to agree. I've seen this go wrong in real deployments: users couldn't find content they expected, and the cause was simply two access models that didn't match. The diagram below shows how the pieces relate:

flowchart TD
    User["User (Copilot licensed)"] --> Query["Copilot app search query"]
    Query --> SemanticIndex["Semantic Index"]
    SemanticIndex --> M365Content["M365 content (Exchange, SharePoint, OneDrive, Teams)"]
    SemanticIndex --> Connectors["Copilot connectors (third party)"]
    M365Content -- "Permissions trimming" --> Results["Search results (permitted only)"]
    Connectors -- "Access mapping" --> Results

Figure: Copilot Search architecture with the semantic index, connectors and permission checks.

Permissions trimming and exclusions decide what users see

The concern I hear most from admins is whether Copilot Search will really only show users what they're allowed to see. From what I've seen, permissions trimming holds up well, and Copilot never gets super-user rights. SharePoint admins do need to keep an eye on their exclusions, though. Exclude a site or library from indexing and it just disappears from Copilot Search. "Restricted" sites and content are hidden from Copilot entirely, even when users could open them in SharePoint.

Practical tip: Review your Restricted SharePoint Search and Content Discovery configuration on a regular basis, and especially after large migrations or site restructuring. A setting nobody noticed can expose important sites or make key knowledge vanish from Copilot.

Bookmarks and acronyms you set up in Microsoft Search (Microsoft 365 admin center → Settings → Search & intelligence) carry more weight in Copilot Search than most people expect. When you add organisational terms, abbreviations and key resources as Bookmarks, you shape which results users get suggested (see Microsoft Search overview). In the organisations where I've helped tune them, users were noticeably happier with search afterwards.

Usage data shows where Copilot Search falls short

Measuring what Copilot Search actually delivers is a task admins skip far too often. In the Microsoft 365 admin center, the Search & Intelligence section gives you usage stats for Bookmarks, top queries and successful or failed searches. The Copilot admin center adds more usage figures, such as how often users really use Copilot Search per licence. That helps you track adoption and spot gaps in your knowledge base. In my experience, just cleaning up and expanding the Bookmarks usually brings a visible drop in failed searches and clearly better Copilot answers.

I think Copilot Search needs real admin care

Microsoft 365 Copilot Search is a big step forward for enterprise knowledge, but only if admins actively manage it. The semantic index, permissions trimming, connector governance and classic enterprise search all affect each other, and you can't set them up once and walk away. My advice is to test early, audit often and tell users clearly what to expect. The better you understand how the parts fit together, the more your users get out of it, and the lower the risk of accidental oversharing or knowledge that can't be found.