It was March 2014. I was attending the Microsoft SharePoint Conference in Las Vegas (the last one of its kind, Microsoft started with their Ignite conference series in 2015) and Microsoft announced the Office Graph, codename Oslo, later renamed to Delve. This was revolutionary. Next-generation search and discovery. Delve was able to proactively show information, personalised for you.

One year later, on March 16th, 2015, Microsoft announced the rollout of Delve to all eligible Office 365 business customers worldwide. The rest is history. Many organisations wanted to switch off Delve, because it showed confidential files, because they didn’t understand the underlying technology (Delve only showed files that YOU had permissions to) and/or because it made them realise the org’s permissions posture in Office 365 was not as they thought it was.

Sounds familiar?

Today, many organisations have the same sentiment towards Microsoft 365 Copilot. Overexposure of content and Copilot using confidential content to craft answers in the conversations with users is a real threat to the adoption of Microsoft 365 Copilot. In this article, I will try to describe your options to deal with the “content discoverability challenge” in Microsoft 365.

The overexposure of content is not new. The introduction of Delve made it visible and sparked conversations in this area, but it has always been a challenge. In my early days as a consultant, I have seen examples where an entire file share structure was copied to SharePoint, including permissions (because stakeholders believed the permissions were set up correctly), and SharePoint Search showed results to users that they were not supposed to see. Modern technology just makes it more visible. As is the case with Copilot. Fortunately, these days we have more controls and reports available than ever. But overexposure will always be a challenge and always something that organisations will have to deal with. Therefore, my first recommendation has nothing to do with technology, but with company policy. These are the topics I will cover in this article:

1. Give users in your organisation the possibility to report over-shared content
2. Exclude SharePoint sites or libraries from Copilot by blocking it from being indexed by search
3. Restrict discovery of SharePoint sites and content with Restricted Content Discovery
4. Enable the Restricted SharePoint Search option
5. Restrict SharePoint site access with Microsoft 365 groups and Entra security groups
6. SharePoint Advanced Management reports and access reviews
7. Labelling your content with sensitivity labels

1. Give users in your organisation the possibility to report over-shared content

This sounds like a trite remark, but I have seen countless organisations where there is not a single place or person to contact when you discover irregularities in content permissions. Or if there is, no one knows about it. It should be completely clear and unclouded who to contact when you are in doubt if what you see, should be seen by you. Moreover, your organisation should encourage to report such discoveries. Make sure you have something about this in your organisation’s guidelines and procedures for handling sensitive or unauthorised content. Don’t hide it somewhere deep in chapter 5, paragraph 6, sub paragraph 3, but make it visible. In fact, the introduction of Microsoft 365 Copilot is an excellent opportunity to emphasise this in your communication.

2. Exclude SharePoint sites or libraries from Copilot by blocking it from being indexed by search

Microsoft 365 Copilot uses the Microsoft Graph to ground user prompts. This makes Microsoft 365 Copilot so useful. It brings parts of your prompt to Microsoft Graph to find content that you have access to and that could be relevant to your prompt. The Graph relies on Microsoft Search to produce the right content. Every SharePoint site has the option to exclude it from appearing in the search results and therewith exclude it from being used in grounding Copilot prompts. You can find this setting by going to the Site Settings (from the homepage of your SharePoint site, click the gear icon in the top right corner -> Site information -> View all site settings) and in the Search section, click Search and offline availability.

The big drawback to this feature, is that the content in that site is no longer indexed, and you will not be able to find any content in the search results. Moreover, if you use web parts that rely on the search index (like the Highlighted content web part), those will no longer work either.

Instead of excluding an entire site, you can also exclude the contents of a document library. You can find this setting by going to the Library Settings (from the homepage of your SharePoint library, click the gear icon in the top right corner -> Library settings -> More library settings) and in the Advanced Settings scroll down and find the Search option.

This way, you could exclude certain libraries in a site while allowing other libraries in that same site. Also, this way you can still use the search-based roll-up web parts for news items on that site for example.

3. Restrict discovery of SharePoint sites and content with Restricted Content Discovery

A slightly less intrusive option to exclude site content from being surfaced in search and Copilot is the use of the Restricted Content Discovery feature. This is a SharePoint Advanced Management feature, which used to be a paid only add-on, part of SharePoint Premium. But since December 2024, SharePoint Advanced Management is provided for free to all tenants with Microsoft 365 Copilot licenses.

With Restricted Content Discovery, you can also limit the ability of end users to search for files in certain SharePoint sites, just like setting the “Indexing Site Content” to No, as discussed in the previous paragraph. The big difference though, is that users can still discover files that they own or recently interacted with. Also, Restricted Content Discovery doesn’t affect searches originating from a site context. The drawback is that this feature can only be enabled through PowerShell for now. This feature cannot be applied to OneDrive sites. Because this is a site-level setting and this needs to be propagated to the search index, keep in mind that if you apply this setting to a large number of sites in a batch operation, it might take a while before the search index is updated for all sites in the queue.

You can find the cmdlets and more information here: https://learn.microsoft.com/en-us/sharepoint/restricted-content-discovery

4. Enable the Restricted SharePoint Search option

Instead of excluding content from the search index, it is also possible to turn off Microsoft Search for all your SharePoint sites, except for up to one hundred curated sites. This sounds quite rigorous, and it is. In fact, Microsoft themselves do not see this option as an end-state, but more as a means to “give you time to review and audit site permissions” and switch to less rigorous options after you are ready with your environment and have more trust in other controls applied.

After you have enabled Restricted SharePoint Search, users (and therefore Copilot) will be able to discover content from:

• An allowed list of curated SharePoint sites set up by admins (with up to 100 SharePoint sites), honouring sites’ existing permissions.
• Users’ OneDrive files, chats, emails, calendars they have access to.
• Files from their frequently visited SharePoint sites.
• Files that were shared directly with the users.
• Files that the users viewed, edited, or created.

Some additional notes that Microsoft published around this feature:

• The limit of up to 100 SharePoint sites includes Hub sites, but not their associated sites. When you enable Hub sites, the associated sites of a Hub site are included in the allowed-list but do not count towards the 100-site limit. When you are picking Hub sites, make sure all the associated sites have proper permissions.
• The total number of files included from the last three bullet points above (frequently visited sites, files shared directly with the user, and files the users viewed, edited, or created) is limited to the last 2000 entities.

At the time of writing this article, you can only enable the Restricted SharePoint Search feature and maintain the curated sites list through PowerShell. You can find the cmdlets and more here: https://learn.microsoft.com/en-us/sharepoint/restricted-sharepoint-search-admin-scripts

When you have enabled this feature in your tenant, your users will see the following message when they access Microsoft 365 Copilot:

Your organization’s admin has restricted Copilot from accessing certain SharePoint sites. This limits the content Copilot can search and reference when responding to your prompts.

5. Restrict SharePoint site access with Microsoft 365 groups and Entra security groups

Earlier, I discussed the Restricted Content Discovery feature, being part of SharePoint Advanced Management. Another SAM feature is Site Access Restriction policies. With these policies, you can restrict access to a site, based on a Microsoft 365 group or an Entra security group. This is particularly useful if you want to make sure that content in a certain site is not shared with users outside of a particular group. Even if a file is shared with someone through a shared link or even if someone previously had access, the policy would prevent that user from accessing that file.

Before you can use Site Access Restriction policies for individual sites, you have to enable site-level access restriction on the tenant level. You can do this in the SharePoint Admin Center. Expand the Policies section in the left-hand menu, click Access control, click Site-level access restriction and enable the feature.

You can also do this through PowerShell: Set-SPOTenant -EnableRestrictedAccessControl $true

Now that you have enabled this feature on the tenant level, let’s have a look how you can enable the restriction policy for individual sites. In the SharePoint Admin Center, go to Active sites and click on the site for which you want to enable the policy. In the site details pane, click the Settings tab and click Edit in the Restricted site access section.

Enable the policy and you are done.                                    

Now, when you go to the Site Permissions panel in the site itself, you will find a new message there, stating that “Restricted site access is on”.

Only owners and members of the Microsoft 365 group that is connected to this site, can access content in this site. Please note that Site Access Restriction policies are applied when a user attempts to open a site or access a file. Users with direct permissions to the file can still view files in search results. However, they cannot access the files if they are not part of the specified group.

For non-group connected sites in SharePoint, like communication sites, you can use Entra security groups or Microsoft 365 groups for the policy. You can configure up to 10 groups.

Since Shared or Private Channel sites are separate sites and not connected to the Microsoft 365 group of the “parent” team site, you need to apply a Site Access Restriction policy to these sites separately. There are some more interesting options within this feature, like sharing controls, configuring a learn more link, and running reports about policy usage and access denials because of these policies, that you can find more info about here: https://learn.microsoft.com/en-us/sharepoint/restricted-access-control

6. SharePoint Advanced Management reports and access reviews

Another very useful SharePoint Advanced Management feature is to initiate site access reviews based on data access governance reports. Perhaps you don’t want to hard restrict access to sites and their content, but you want site owners to be responsible for managing and maintaining access to their sites. You can help them by providing the reports for them to review and let them take action from there.

Site access reviews are available for the following reports:

• Sharing link reports (Anyone, People in your organisation, Specific people shared externally)
• Content shared with “Everyone except external users” reports
• Oversharing baseline report using permissions (only available through PowerShell)

You can find the reports under the Reports section in the SharePoint Admin Center, by clicking Data access governance. From there, you can view the various reports available or run the reports if they have not been run yet. It can take quite some time to run a report, and you can only run a report once every 24 hours.

In the screenshot below, you can see that I have created and run a report that will show sites where “Everyone except external users” was added to the site membership in the last 28 days.

The report has found one site where this is the case. This can be considered as oversharing, because this means that there is content in that site that is accessible to everyone with an account in my organisation, where the team site itself has restricted access to only a few team members. From this same screen, we can initiate a site access review, by selecting the site and clicking the button above. In the next screen, we can add a personalised message and send the review request.

This email looks as follows:

When you click the View SharePoint groups button, you will be directed to the site reviews page of that SharePoint site, where you can check the permissions and take action if needed.

Do not forget to tell your site owners to mark the review as complete with the button at the bottom of the review page. This helps to keep track of all the site access reviews you sent out, as you can see below.

You can find more information about data access governance reports and access reviews here: https://learn.microsoft.com/en-us/sharepoint/site-access-review

7. Labelling your content with sensitivity labels

Sensitivity labels are a way to identify and classify the sensitivity of your organisation’s content and can help in adding an extra layer of protection to your data. Implementing sensitivity labels and policies to protect your data is a good idea overall anyway, but with Copilot you get a few extra perks that can help identifying sensitive data and protecting your data from oversharing.

If you have implemented sensitivity labels in your tenant, you get the following in your Copilot conversations:

• Sensitivity labels are shown in the returned results. This means that you as a user can assess if you think the data referenced by Copilot and used to craft the answer is suitable to share with the audience you had in mind.
• If Copilot creates new content from labelled content, the sensitivity label from the source item is automatically applied to the newly created content.
• If content is labelled with a label that applies encryption, Copilot checks the usage rights for the user. For Copilot to return data from that item, the user must be granted permissions to copy from it.

There’s one more feature with sensitivity labels that I’d like to discuss. That’s a setting to “prevent connected experiences that analyse content”. Although Microsoft 365 Copilot is named as one of the affected connected experiences, I wonder if this setting was designed for Copilot or that it just happens to affect Copilot. The reason I say this, is because it works quirky and doesn’t seem to really protect files from being analysed by Copilot.

First things first. What does this feature do? This setting lets you prevent content in Word, Excel, PowerPoint, and Outlook from being sent to Microsoft for content analysis as a privacy control. The following connected experiences will be affected by this setting:

• Acronyms in Word
• Automatic alt txt in Word, PowerPoint, Excel, Outlook
• Automatically apply or recommend sensitivity labels in Word, PowerPoint, Excel, Outlook
• Microsoft 365 Copilot in Word, PowerPoint, Excel, Outlook
• Microsoft Purview Data Loss Prevention policy tips in Outlook
• PowerPoint Designer in PowerPoint
• Similarity checker in Word
• Translator in Word, PowerPoint, Excel, Outlook

So, yes, Microsoft 365 Copilot is mentioned, but only in the Office apps (sorry, I should say Microsoft 365 Apps, I think). In fact, Microsoft mentions the following:

Although content with the configured sensitivity label will be excluded from Microsoft 365 Copilot in the named Office apps, the content remains available to Microsoft 365 Copilot for other scenarios. For example, in Teams, and in Graph-grounded chat in a browser.

For things like acronyms, similarity checker and translator, which use an external service and content leaves your Microsoft 365 service boundary, I understand this applies to the M365 Apps. But for Copilot this doesn’t make a lot of sense in my opinion. First, Microsoft guarantees your content doesn’t leave your Microsoft 365 service boundary when you use Copilot. Secondly, why would I use this if I can still access the labelled content from M365 Chat for example? And in my experience, it works even quirkier than that, as I will demonstrate below.

Let’s start with configuring the setting. You can only do that through PowerShell. Connect to Security & Compliance PowerShell (ExchangeOnline module) first and then use:

Set-Label -Identity “your label name” -AdvancedSettings @{BlockContentAnalysisServices=”True”}

Next, I created a new document with a Star Wars Galactic Odyssey story, featuring me as a main character (yes, I have aspirations) and I labelled that document with my “Exclude from Copilot” label. Immediately, the Copilot icon greyed out in Word and I could no longer use Copilot from within that document in Word.

Interesting, I did not quite expect that. I thought I would protect this document from being used in other Copilot experiences, but not that I could no longer use Copilot in this document itself. It does make sense though.

All right, now what if I try to access this document from a new Word document? That’s where things become quirky. My Odyssey story does pop up when I try to reference it:

Then, when I click Generate, my new blank document gets a header title, but no further content. And it is automatically labelled with the same label as the document I tried to reference. To me, this is odd behaviour and hard to explain to end users.

I wanted to try one more thing. What happens when I craft a prompt in Microsoft 365 Chat, which I know will try to use this one document in my tenant when it can because it is the only document with content about my Galactic Odyssey? Indeed, it references this document and it also shows the label I applied to this document.

In summary, I like this setting if you want to absolutely make sure that certain documents are not being processed outside your Microsoft 365 service boundary, but it is not very useful in combination with Copilot and even invokes odd behaviour.

Back to sensitivity labels in general. Please keep in mind that implementing sensitivity labels is a project on itself. Although technically not very hard, getting the right policies defined and educating your users requires planning, time and dedication. But if you do it right, sensitivity labels will help you achieve a higher content security and compliance posture in general and some very useful features in Copilot in particular.

Conclusion

As we are all aware, many organisations struggle with overexposure of data in their environment and in the age of Copilot, this becomes more visible than ever. The good news is that there are quite a few options at your disposal to help you improve the security of your content. I am incredibly pleased that Microsoft decided to give all Microsoft 365 Copilot organisations the SharePoint Advanced Management features for free. As we can see in this paper, SAM can play a vital role in improving your content security posture, but there are other options too. I hope this paper will help you in setting up the right permissions and governance and will help your organisation become more confident about their security posture. Happy copiloting!

Update 2 Jan 2025: Added an explanation of the “prevent connected experiences that analyse content” feature in chapter 7 “Labelling your content with sensitivity labels”