So the world has gone Copilot crazy, everyone who is at all interested in digital technology, AI and all the potential workplace enhancement glory that comes with a digital assistant will no doubt have looked at Copilot, ChatGPT or others depending on your preference and which way you swing.
However for these AI beasts to provide you with the best responses to answer your daily questions and meet your needs, what do they require? Data, lots of data, they need to be able to ingest as much data as possible and then use this index to feed you the answers that you may seek!
Microsoft Copilot has a rather clever way of ensuring the responses shown are only sourced from the data you already have access rights for, because can you imagine the workplace drama if the responses you got back contained information you shouldn’t be seeing, oh the legal and HR teams would be having a field day!
So Microsoft have invested a lot of time, funding and resources to ensure that your Enterprise Copilot ensures your data always remains within your tenancy but also that any data used to generate your responses adheres to the pre- existing data security model within M365 and Azure.
So far so good! Now you may currently be asking, “Gary where are you going with this”… well stay with me, just remember the words Restricted SharePoint Search
Restricted SharePoint Search – Join Me, Move Me, Leave Me
So Copilot makes sure you only see the data you can already access, it respects all purview controls and data sensitivity requirements and the data isn’t used to do any model training, whats the problem?
Well this of course assumes a perfect world where the current user access controls and security groups/permissions granted to the user base are reflective of the data that they should be seeing…..
Penny dropped yet?
In my many many years of technology consulting I have rarely come across an environment where security permissions are 100% and users only have access to the relevant content to perform the current role they are in.
Users are by nature changeable beings, people rarely stay in one role operating on one set of data for the length of their careers, people join organisations, they move throughout the organisation and then they may or may not leave.
Now of course in the various stages of their employment journey they will be granted access to do a specific role or access a set of files for a specific project etc and all these changes will absolutely be managed through a bulletproof Joiners, Movers, Leavers process, won’t it…. No seriously it will won’t it…
Search my data, wait no … not all my data!
Oh dear its not is it ?
Well it’s probably manageable as lets face it users won’t be digging around in random SharePoint libraries looking for content in some obscure Excel or Word document that someone shared with them 4 years ago by mistake, I mean the chances of that are pretty slim really..
I mean it’s not like there is some semi sentient AI engine quietly adding accessible content into a semantic index of content that the user can ask questions of now is there, I mean that would be crazy talk…. What’s that? You have just switched on Copilot for your entire user base…….oh Seattle we might have a problem ….
Now, I am no way saying turning on Copilot is a bad thing there is so much capability and time saving AI solutions in the platform it would be silly not to look to take advantage of this awesome technology! However what the users have in Copilot is a way to query the vast amounts of data stored within your M365 environment through natural language.
So if a user was so inclined they could ask Copilot something like,
“Act as an HR Talent partner and find me any job descriptions or specifications that contain salary banding for a solutions architect”.
If they also happened to have worked on a project that required access to HR data in the past which was granted “temporarily” and well not removed, well you get the picture….So, what can we do about it ? I hear you cry.
Enter Restricted SharePoint Search to Save the Day
Well this is where we can leverage a new feature which is currently on the M365 Copilot roadmap, Restricted SharePoint Search or “RSS” yes not the web based news feed standard we all know and love.
What this new Restricted SharePoint Search functionality enables is for the admins of your environment to provide a list of up to 100 SharePoint site collections that Copilot is able to access and index, it of course respects any user access permissions as one would expect.
So Restricted SharePoint Search is off by default. If you decide to enable it Copilot and non-Copilot users will be able to find and use content from:
- An allowed list of curated SharePoint sites set up by admins (with up to 100 SharePoint sites), honoring sites’ existing permissions.
- Content from their frequently visited SharePoint sites.
- Users’ OneDrive files, chats, emails, calendars they have access to.
- Files that were shared directly with the users.
- Files that the users viewed, edited, or created.
So this feature really tightens the belt around what Copilot can index and thereby use as content to generate it’s responses from. In effect creating a site based access control list or whitelist of approved sites!
Awesomeness, that’s great news! Lets enable it and crack on. Well it is awesome but there is a nuance which may make things abit less rose tinted glasses.
Here’s the kicker, when you enable this feature you also apply the same site whitelist to the basic SharePoint search. In essence this whitelist will apply to every user in the tenant, Copilot enabled or not.
Search results and Copilot search results will be limited (enabling this feature impacts the search experience, even for non-Copilot users).Now this may not be a problem for SME’s who know their data landscape inside out; however if you are a global firm with 1000’s of SharePoint sites using this method will in effect stop all of the other sites being searchable in SharePoint.
Not so good….
Maybe it’s a case of a “Bottoms Up” Restricted SharePoint Search
However fear not there is a solution but it’s more of a “bottoms up” approach.
Copilot obviously uses the same index for it’s semantic search as SharePoint which is why the problem exists in the first place, however there is a little feature of old whereby you can force a SharePoint site collection to be hidden from being Search Indexed at the site level.
So theory is instead of Whitelisting up to 100 sites for Copilot to use you can specifically remove known sensitive sites from being able to be shown in the search results and thus Copilot.
This approach like the initial Restricted SharePoint Seach option will affect all users Copilot or Non Copilot but it offers in my opinion a more granular approach than the “deny all but this list” approach of Restricted SharePoint Search
So whilst this approach offers a more granular control over what sites are being indexed you will have to know where your sensitive data sits and what sites to block, which may require a lot more effort upfront in terms of data analysis.
But IMHO it’s a more expansive option in allowing Copilot access to as much data as possible whilst still limiting the sensitive data (that you know about)
In closing the only other option I can currently see is to do a full security and permissions analysis for any users that are being onboarded as part of your Copilot rollout and adjust their permissions and access rights so they are relevant to their current role and data needs, which of course is already managed with your 100% perfect JML process isn’t it !
