Before you roll out Microsoft 365 Copilot: an oversharing and permissions checklist

Microsoft’s position is precise. Copilot only surfaces organisational data that an individual user has at least view permission to, and its Semantic Index only reaches content the current user is authorised to access [1]. None of that is wrong. The trouble is what view permission means in a tenant that has been collaborating for years: the HR site shared with the whole company for one policy launch, the finance folder whose inheritance was broken for a project that ended, the team made public because private was one more click.

While finding a file meant knowing it existed, most of that access sat unused. Copilot does the finding, on every prompt, so access that was technically open and practically hidden becomes an answer. Microsoft’s deployment guidance for Copilot treats this as step one, ahead of guardrails and regulatory work: remediate oversharing, then set guardrails, then meet regulations [2].

The UK government flagged the same risk at scale. In its cross-government Microsoft 365 Copilot experiment, with 20,000 government employees from 30 September to 31 December 2024, the Government Digital Service reported that Copilot’s searching with a user’s access “may highlight issues when users have access to files they shouldn’t”, and told organisations to bring their information and knowledge management up to date [3].

My view is that this clean-up belongs at the start of a Copilot rollout, and a plan that leaves it for after launch is the wrong plan. Switching licences on over an unreviewed tenant is an expensive way to run an access review, because your staff find the problems before your administrators do. If Copilot is not yet settled as your assistant, a side-by-side of the ChatGPT and Claude enterprise plans covers what each of those vendors publishes on admin controls and data location.

Oversharing is rarely one bad decision. It is a handful of small mechanisms, and Microsoft’s reports find each of them separately. This is what to look for, how each one reaches Copilot and which report shows it.

The link rows are from Microsoft’s explanation of how shareable links work [6], and the group, inheritance and ownership rows from its pages on data access governance reports and the content management assessment [4, 5]. The detail on “People in your organization” links matters. They only become Copilot’s business once redeemed, but posting one in an email to a hundred colleagues redeems it for each of them [6].

Two points are my reading rather than Microsoft’s words. “Everyone except external users” is the one to fix first, because it opens a site to everybody at once without any link having to travel. And ownerless sites are the ones that stall the whole project, because the review process Microsoft offers is addressed to a site owner [14].

The access fix runs at the pace of site owners, and the rollout rarely waits for it. Microsoft’s answer is interim protection: keep sensitive sites out of Copilot’s reach while their access is corrected, check that it holds, then take it off [2]. There are two tools for this, and they do different jobs.

The Restricted Content Discovery detail is from Microsoft’s page on it [9], and the DLP detail from Purview’s page on the Copilot location [11]. Microsoft now points to Restricted Content Discovery in place of Restricted SharePoint Search, the older allow-list approach capped at 100 sites, which it is retiring: new enablement has been blocked since 31 July 2026 [10], so a tenant still running it should plan its removal into the same project.

Microsoft asks for Restricted Content Discovery to be used selectively, because every site behind it makes Copilot’s answers less complete [9]. I agree, and I would add a date: each restricted site gets an owner and a target date to come out, or interim becomes permanent. Then prove the protection works by asking Copilot, as an ordinary user, for something the site holds, and confirm it in Purview’s audit records, which Microsoft’s guidance also asks for [2].

Two DLP details catch people out. A policy change can take up to four hours to reach Copilot, and DLP does not scan files a user uploads straight into a prompt, only the text they type [11].

Interim protection buys time. The fix is removing access nobody should have, and Microsoft’s guidance splits the work between administrators and site owners [2].

The baseline is from Microsoft’s page on data access governance reports [5], the removals and ownership steps from its Copilot foundation guidance [2], the reviews from its page on site access reviews [14] and restricted access control from its own page [15].

Restricted access control is stronger than Restricted Content Discovery, because it changes who can get in rather than what search shows. It is also blunter. Membership of the control group grants nothing on its own, and a user needs both the site permission and the membership [15], so test it with the people who actually do the work before it goes on a busy site.

Group membership is the other half, because most SharePoint access runs through groups. Microsoft Entra access reviews ask group owners or named reviewers to recertify who is in a group on a schedule, guests included [16]. The cleaner answer for staff is to stop managing membership by hand and drive it from the HR record, so leavers lose access because a record changed rather than because somebody remembered. A worked example of provisioning access from the HR record, for more than 1,000 users across 600 groups, is in the case files.

Labels come up in every Copilot plan, and they are credited with more than they do. Microsoft describes what they add for AI [12]. When a labelled file or email is open in Word, Excel, PowerPoint or Outlook, the app shows the label and its markings. Where the label applies encryption, a user needs the EXTRACT usage right as well as VIEW for Copilot to return that data.

So a label without encryption removes nobody’s access and does not stop Copilot using the file for someone who can open it. To keep labelled content out of Copilot’s answers you need the DLP rule above, which acts on the label [11]. Labels and DLP are one control in practice, and I would design them together.

Two settings make labels count against oversharing. Enable sensitivity labels for Office files in SharePoint and OneDrive, because without it the encrypted files Copilot can reach are limited to files open in Office apps on Windows [12]. And label sites and teams as well as files: a container label can set privacy, external sharing and access from unmanaged devices and, through PowerShell, the default sharing link [13]. Microsoft’s guidance is to require a site label when a site is created, so the sharing settings are right from the first day [2].

One trade-off to decide deliberately: some container label settings hand site owners control of external sharing that was otherwise an administrator’s, because applying or changing the label changes the setting [13].

Microsoft ties several of these tools to the Copilot licence itself. Once at least one Copilot licence is assigned, SharePoint administrators get the SharePoint Advanced Management features that support a Copilot deployment, which include the assessment, the reports, site access reviews, Restricted Content Discovery and restricted access control [18].

The rows are from Microsoft’s pages on each control [4, 5, 9, 14, 15, 16], its list of the Advanced Management features in Copilot licences [18] and its Copilot foundation guidance [2]. The one Advanced Management feature Microsoft lists as outside the Copilot licence is restricted site creation by apps, which needs the Plan 1 add-on [18].

A clean tenant drifts back if nothing changes how new sites are created and shared. Microsoft’s second step is exactly that: secure defaults at the point of creation, and guardrails that keep being checked [2].

The defaults, archive and monitoring steps are from Microsoft’s Copilot foundation guidance [2], the link settings from its pages on the default link type and on sharing settings [8, 7], the lifecycle policies from its SharePoint Advanced Management overview [17] and the 30-day rerun from the assessment page [4].

The part software does not solve is ownership. Every one of these controls ends in a person who approves access or answers a review, and if nobody in the business owns that job, the tenant drifts back however good the admin work was. For the policy that names those owners, a template for an AI policy with an owner on every clause is a place to start.

We roll out Microsoft 365 Copilot, and this checklist is the first workstream of how we do it. We run the assessment, put interim protection on the sites that need it, work through the access fixes with site owners, and set the labels, DLP rules and defaults that keep the tenant closed after launch, before the pilot and the wider rollout. That is our AI governance implementation engagement applied to Microsoft 365: permissions and data rules the tenant enforces, rather than ones written into a policy nobody reads. The nearest published work is our engagement file on AI platform enablement at a large international marketing agency, where we hold the lead architect role on the platform underneath its organisation-wide AI programme.

We work with clients across the UK, the US and the Gulf, and we do not resell Microsoft licences, so the advice on what to switch on is not tied to what we sell. A fixed-scope clean-up can start within a day of the scope being signed, and if you already have a scoped job, we can resource it on contract from the collective of associates who work with us, held to the same standard. The call is booked from the end of this page.