Skip to content
Guides

Microsoft 365 Copilot Access Controls: How to Make Them Work

Copilot does not bypass your permissions. It honours them, and that is exactly the problem. Here is the five-step sequence enterprise IT teams should run to tighten Microsoft 365 Copilot access controls before rollout turns permission debt into an incident.

 
Microsoft 365 Copilot access controls guide for enterprise IT teams blog article

Why Microsoft 365 Copilot Access Controls Surface More Than You Expect

Microsoft 365 Copilot access controls are not a Copilot setting. They are your SharePoint permissions, seen under a spotlight for the first time. Copilot grounds every answer in Microsoft Graph, which spans every SharePoint site, OneDrive file, Teams chat, and Exchange message a user may already view. Ask it “what is our Q3 budget forecast?” and it searches that whole surface, then writes an answer.

Two things surprise most enterprise IT teams at this point:

  1. Copilot finds files users forgot they could open. A finance spreadsheet shared three years ago with a broad department group is still in scope. Nobody would have found it by browsing. Copilot finds it in one query.
  2. Copilot turns implicit access into explicit answers. People never knew they could read that confidential HR file, because they never went looking. Now Copilot answers their question using it.

Microsoft’s documentation is explicit: Copilot “only surfaces organizational data to which individual users have at least view permissions.” That boundary holds. However, it holds only as tightly as the permissions behind it. In other words, Copilot does not create exposure. It reveals exposure that was already there.

 

Step 1: Audit SharePoint Permissions Before Enabling Copilot

Therefore, measure your exposure before Copilot starts answering questions, not after.

SharePoint Advanced Management (SAM) is the right instrument. It ships with Microsoft 365 Copilot licences and gives you three reports that matter:

  • Site access reports showing which sites grant broad permissions — everyone, all employees, or large security groups
  • Oversharing reports flagging files shared through “anyone with the link”
  • Inactive site detection so you can retire content that should not be in scope at all

Run the oversharing report first. In the tenants our team has worked in, a substantial share of SharePoint sites still carries “Everyone except external users” on at least one document library. That is content Copilot can reference for any employee who asks the right question.

This audit is tedious, and we will not pretend otherwise. Most enterprises have accumulated hundreds of sites over a decade. But there is no shortcut here, because Copilot’s permission enforcement is only ever as accurate as the permissions themselves.

 

Step 2: Apply Sensitivity Labels Before Copilot Reads the Files

Microsoft Purview sensitivity labels make Microsoft 365 Copilot access controls auditable rather than merely assumed. Labels give you a second enforcement layer that operates on the content itself.

When you label a document, three things follow:

  • Copilot honours the label’s usage rights at query time
  • Purview DLP policies can keep labelled content out of Copilot responses entirely
  • Audit logs capture every prompt and response that touched protected content

Priority order matters. Start with your highest-sensitivity categories: board documents, personal data covered by Quebec’s Law 25 or the GDPR, M&A files, and HR records. Label those first. You cannot stop Copilot from reading a file the user can already open, but Purview DLP can stop it from surfacing that content in an answer.

One practical caveat: sensitivity labels require Microsoft Purview Information Protection licensing, typically bundled in Microsoft 365 E5. If you sit on E3, budget for the upgrade before you assume Purview will solve your governance problem.

 

Microsoft shipped Restricted SharePoint Search (RSS) as a stopgap, letting you cap which sites Copilot could reach while you cleaned up permissions. Microsoft has since blocked new RSS enablement and is retiring the feature.

The replacement is Restricted Content Discovery (RCD). RCD limits Copilot and enterprise search results to sites you have explicitly verified, and it drops the 100-site cap that made RSS unusable at enterprise scale. If you are configuring Microsoft 365 Copilot access controls today, RCD is the mechanism to reach for.

Be clear about what RCD is not. It is not a security boundary. It limits discoverability, not access, so a user who already knows a file URL can still open it. RCD buys you time to clean up permissions. It never substitutes for cleaning them up.

 

Step 4: Audit ACL Refresh on Every Graph Connector

This is where most Copilot governance advice stops short, so it is worth being precise.

Copilot uses the Semantic Index, Microsoft’s internal index built on Microsoft Graph, to retrieve content before passing it to the language model. That index checks whether the querying user has access before it returns a document — late-binding enforcement, evaluated at query time against live permission state. For pure Microsoft 365 content, this works reliably.

The problem starts when you extend Microsoft 365 Copilot access controls beyond Microsoft 365. Microsoft Graph connectors pull in ServiceNow, Confluence, Salesforce, or internal file shares. Most of them check permissions at index time — early-binding — and store the Access Control List alongside the document. Consequently, if group membership changes after indexing, that stored ACL stays stale until the next crawl.

So if you index external systems, do three things before users start querying them:

  1. Match crawl frequency to how often group membership actually changes in your organisation
  2. Test propagation directly: add a test user to a group, then measure how long before Copilot’s answers reflect the change
  3. For high-sensitivity sources, ask whether a connector belongs there at all, or whether a dedicated permission-aware search platform is the better answer

This is the technical line between a useful assistant and a data-leak incident. We have seen organisations with impeccable SharePoint hygiene create fresh exposure by connecting a ServiceNow instance without ever auditing its ACL refresh schedule.

 

Step 5: Configure Microsoft Entra ID Groups Before Rollout

Copilot’s permission model is only as precise as your group structure in Microsoft Entra ID, formerly Azure Active Directory.

If your SharePoint sites grant access to individual users instead of security groups, every permission review becomes manual and every review cycle becomes unaffordable. Before you roll out broadly:

  • Convert individual-user SharePoint grants to Entra ID security groups wherever the content model allows it
  • Turn on Entra ID Access Reviews so managers recertify group membership, not IT
  • Enable Privileged Identity Management for groups that gate sensitive sites, so elevated access stays time-bound rather than permanent

None of this is Copilot-specific advice. Copilot simply makes the cost of stale group membership visible in a way that passive file access never did.

 

The Microsoft 365 Copilot Access Controls Decision: Three Questions

Here is the framework we walk enterprise clients through before they enable Copilot for a broad user population.

1. Do you know which SharePoint sites are broadly permissioned? If you cannot answer that from a report, run the SAM oversharing audit before anything else. Guessing is not a governance posture.

2. Have you labelled your highest-sensitivity content? If HR, legal, and financial documents sit unlabelled, Copilot will answer questions using them, and no DLP policy exists to stop it.

3. Are you extending Copilot past M365 through Graph connectors? If so, each connector needs its own explicit ACL audit before a single user queries it.

Three “yes, done” answers mean your Microsoft 365 Copilot access controls are working as designed. Any “not yet” tells you where to start — and it is never with Copilot’s settings. It is with the permissions infrastructure underneath them.

 

What Copilot Cannot Do (By Design)

To be equally direct about the platform’s limits:

  • Copilot cannot open files a user has no permission to view. The Semantic Index enforces that boundary on every query.
  • Copilot cannot be granted elevated access on a per-query basis. There is no configuration that lets it exceed the querying user’s existing rights.
  • Copilot does not train the underlying models on your organisational data. Microsoft’s privacy documentation states plainly that prompts, responses, and accessed data stay out of foundation-model training.

What Copilot can do is make someone aware of content they technically could always reach but would never have found by hand. That is a permission management problem rather than a Copilot problem. Copilot just makes it urgent.

 

When Microsoft 365 Copilot Access Controls Need a Permission-Aware Search Layer

For some environments, Microsoft’s native governance tooling is not enough on its own. That threshold usually arrives with 10,000+ employees, regulatory obligations like HIPAA, Law 25, or SOC 2, or complex permission inheritance carried over from legacy systems.

In those cases, a dedicated permission-aware platform such as Coveo can extend reach across non-Microsoft sources while enforcing document-level permissions at the index itself. Coveo resolves permissions at crawl time and applies them at query time, and it supports near-real-time ACL refresh on supported connectors. That is a meaningful difference from the periodic-crawl model most Graph connectors rely on.

Sengo is an official Coveo implementation partner, and our team includes a former Coveo backend developer who knows the indexing and security-identity layer from the inside. We have delivered this architecture for enterprise clients in financial services and the public sector, where “probably fine” is not an acceptable answer on data exposure. Our Coveo practice covers that work, and our search and discovery solution sets out how the pieces fit together. If your content spans both official languages, our guide to enterprise search software for bilingual organizations is the better starting point.

The sequence, in short: audit permissions, label sensitive content, restrict discovery while you remediate, then decide whether Copilot alone carries your whole estate — or whether a permission-aware layer belongs alongside it.

Contact us about your AI-enabled intranet

Frequently Asked Questions

No. Copilot uses the same Microsoft Graph permission model as every other Microsoft 365 service, and it only surfaces content the querying user already has at least view permission on. The Semantic Index enforces that on every query. So if Copilot returns a file you did not expect, check the SharePoint permissions on that file. The user can reach it.

Copilot is exactly as safe as your permission model. It adds no risk beyond the access rights you have already granted. The real risk is that Copilot makes it trivial to query across everything accessible at once, which surfaces files users could always open but would never have found by hand. Microsoft Purview sensitivity labels and DLP policies let you keep labelled content out of Copilot responses even when the user has view access to the underlying file.

Restricted SharePoint Search (RSS) was a temporary control that limited Copilot and enterprise search to a manually managed allow list of up to 100 SharePoint sites. Microsoft has blocked new RSS enablement and is retiring it. Restricted Content Discovery (RCD) replaces it with a more scalable mechanism that has no arbitrary site cap. Neither one is a security boundary. Both are discoverability controls that buy you time during permission remediation.

Copilot indexes external systems through Microsoft Graph connectors. Most connectors use early-binding ACL enforcement: permissions are captured at crawl time and stored with the indexed document. Consequently, if group membership changes between crawls, the stored ACL can go stale. For high-sensitivity external content, audit the connector ACL refresh schedule before you enable Copilot access to that system.

Yes. Copilot searches everything a user has permission to access, including files shared years ago that nobody remembers. That is precisely why a SharePoint oversharing audit through SharePoint Advanced Management is the recommended first step before a broad rollout. The goal is not to limit Copilot. It is to clean up permissions that were always too broad, before Copilot made them consequential.

No. Microsoft’s privacy documentation is explicit: prompts, responses, and data accessed through Microsoft Graph are not used to train foundation models. Your organisational data stays inside your Microsoft 365 tenant boundary, governed by the data processing terms you already have.

It depends on your environment. For most M365-centric enterprises, Copilot’s Semantic Index combined with SharePoint Advanced Management and Purview is sufficient. For organisations with complex multi-system estates, strict regulatory requirements, or fast permission propagation needs from non-Microsoft sources, a dedicated platform such as Coveo alongside Copilot gives finer control. The choice is rarely binary: most large deployments run both.

Sources & References

  1. Data, Privacy, and Security for Microsoft 365 Copilotlearn.microsoft.com
  2. SharePoint Advanced Management overviewlearn.microsoft.com
  3. Restricted SharePoint Searchlearn.microsoft.com
  4. Restricted Content Discoverylearn.microsoft.com
  5. Microsoft Graph connectors overviewlearn.microsoft.com
  6. Microsoft Purview for generative AI appslearn.microsoft.com
  7. Microsoft Entra ID overviewlearn.microsoft.com
  8. Microsoft Graph overviewlearn.microsoft.com
Sengo Robot  Nikko
I Co-wrote this with a human 😉