Module 4 of StartCloud's Copilot Essentials learning pathway, in six short units with a knowledge check: why Copilot makes oversharing visible, how its permissions model works, how to audit SharePoint and OneDrive sharing, the temporary brakes versus the real permissions fix, and a step-by-step pre-rollout checklist.
Getting your data ready for Copilot
The day Copilot finds the payroll spreadsheet
Here is a story we hear a version of every few months. A business switches on Copilot, and within the first week someone asks it something harmless like "what do we pay our project managers?" Copilot, being helpful, finds a salary spreadsheet sitting in an old SharePoint site from 2019 and summarises it beautifully.
Nobody hacked anything. Copilot did not break a single rule. That spreadsheet had been sitting in a site shared with the whole organisation for six years, and the only thing protecting it was that nobody knew it was there. Copilot only surfaces content a person already has permission to open. The trouble is that in most organisations, "already has permission" covers a lot more than anyone realises.
Before Copilot, that gap did not matter much. Finding an overshared file meant clicking through years of site rubble, so in practice nobody ever did. Copilot removes the digging. Ask a question, and anything your permissions technically allow becomes one polite answer away.
For years, "nobody will ever find it" did the work of real security. That was the spare key under the doormat: fine while nobody looked. Copilot is the friendly new neighbour who checks every doormat the moment someone asks where the key is. The fix is not to be cross with the neighbour. It is to stop keeping keys under doormats.
This module is about closing that gap before rollout rather than after an awkward all-staff email. The good news: the work is well understood, Microsoft gives you purpose-built tools for it, and most of it makes your environment safer whether or not you ever buy a Copilot licence.
How Copilot decides what it can see
Copilot does not get its own set of keys. When someone asks it a question, it reaches into Microsoft 365 through Microsoft Graph using that person's identity, and it can only ground its answer in content that person is already authorised to open. Microsoft is clear on this point: Copilot has no tenant-wide visibility, and it cannot access anything the signed-in user cannot.
That is reassuring, and it is also the whole problem in one sentence. Copilot's boundary is your permissions. If your permissions are tidy, Copilot is tidy. If a site was shared with the entire organisation in a hurry back in 2019, that site is inside the boundary for every single staff member.
"Summarise our current salary bands"
Copilot checks what Sarah can access, not what exists
- Her own OneDrive files, email, and calendar
- Team sites she is a member of
- Files shared directly with her
- Any site open to "Everyone except external users", including that payroll site from 2019
- The directors-only board site
- HR files locked to the HR security group
- A colleague's private OneDrive
- Anything encrypted by a label that excludes her
The payroll site sits inside the boundary not because Copilot misbehaved, but because someone once clicked "share with everyone" and nobody ever un-clicked it.
So the job before rollout is to make sure the boundary itself is right, which starts with finding out where it currently leaks.
Find your overshared data
You cannot fix what you have not found, and guessing does not work. Most organisations that run their first proper audit are surprised by the result, usually in the "how long has THAT been open" direction. Three things account for most of the risk.
A built-in group that means your entire organisation. Any site or file shared with it is effectively public internally, and it is the single biggest source of Copilot surprises.
"Anyone" links and "People in your organisation" links created over the years. Each one widens who can open a file, long after everyone forgot it exists.
Sites from finished projects and departed staff. No owner means nobody reviewing access, and "public" sites created before anyone thought about defaults.
Where to actually look
The SharePoint admin centre has a purpose-built section for this: data access governance reports, under Reports. The site permissions report gives you a baseline snapshot of which sites have the broadest access, including every site touched by "Everyone except external users". Activity reports then show where new sharing links and organisation-wide shares were created in the last 28 days, so you can see oversharing as it happens, not just the historical pile.
The full set of reports comes with SharePoint Advanced Management, which is included with every Microsoft 365 Copilot licence, so if you are planning a Copilot rollout you already own the audit tooling. Its content management assessment also flags oversized audiences, broken permission inheritance, and inactive or ownerless sites in one pass.
If you have worked through our Security Essentials pathway, this will feel familiar. The SharePoint and OneDrive sharing controls module covers the tenant-wide sharing settings that stop the pile growing back, and it pairs naturally with the audit work here.
If you would rather not work through it yourself, this is the whole of our secure Microsoft Copilot deployment service: the tenant review, the oversharing report, and the remediation done before anyone gets a licence.
You do not need every site perfect before rollout. Rank by risk: sites that are both broadly shared and likely to hold sensitive content (finance, HR, payroll, board papers) go first. A ten-year-old site full of morning tea rosters can wait its turn.
The brakes and the fix
Once the audit hands you a list, you have three levers, and they are not interchangeable. One buys time, one fixes the problem, and one makes the fix permanent. Rolled out in that order, they work beautifully. Used as substitutes for each other, they do not.
Restrict what Copilot can find, for now
SharePoint Advanced Management includes Restricted Content Discovery, a per-site switch that keeps a site out of Copilot and organisation-wide search while you review it, without changing any permissions. Its older cousin, Restricted SharePoint Search, flips the model to an allow list of up to 100 approved sites. Both are explicitly designed by Microsoft as short-term measures, and Restricted SharePoint Search is being retired, with new enablement blocked from 31 July 2026.
- Buys time while you audit and remediate
- Does not change a single permission
- Blunts Copilot: less content means weaker answers
- Users can still open hidden files directly
Repair the permissions themselves
The durable answer is boring: make access match reality. Remove "Everyone except external users" where it does not belong, use restricted access control to lock high-risk sites to a defined security group, send site access reviews to site owners so the people who know the content confirm who should have it, and give ownerless sites an owner.
- Fixes the problem for Copilot, search, and humans alike
- Restricted access control trims site access to a named group
- Site access reviews put decisions with site owners
- Tighter sharing defaults stop the pile growing back
Sensitivity labels and DLP with Purview
Mature data protection means the file carries its own protection wherever it goes. Microsoft Purview sensitivity labels classify and encrypt sensitive content, and Copilot honours the usage rights: if the label's encryption excludes a user, Copilot will not surface that content to them. Data loss prevention policies can also exclude labelled content from Copilot processing entirely.
- Protection travels with the file, not the folder
- Copilot respects label encryption and usage rights
- DLP can keep labelled content out of Copilot's reach
- Purview's DSPM for AI flags oversharing risks on an ongoing basis
Microsoft's own documentation is clear: the search restrictions are not a security boundary. A site hidden from Copilot is still wide open to anyone who navigates to it, and the restrictions cap how useful Copilot can be while they are on. Treat the brake as a brake. The destination is fixed permissions and labelled data, at which point you release it.
Labels are a project in their own right, and we cover them properly in the Microsoft Purview module of our Security Essentials pathway. If Copilot is the reason you finally start that project, it will not be the worst thing Copilot ever made you do.
Your pre-Copilot checklist, step by step
Here is the whole module as one runnable sequence. It follows the same shape as Microsoft's own oversharing blueprint for Copilot deployments: find it, brake it, fix it, label it, verify it.
- 1Tighten your sharing defaults. In the SharePoint admin centre, set default sharing links to "Specific people" and rein in "Anyone" links. This stops new oversharing while you clean up the old.
- 2Run the data access governance reports. Start with the site permissions baseline report, then the "Everyone except external users" and sharing links reports. Export the lot; this is your worklist.
- 3Triage by risk. Sort the list by two questions: how sensitive is the content, and how broad is the access? Sites that score high on both (finance, HR, payroll, board) are your first wave.
- 4Apply the temporary brake where needed. Turn on Restricted Content Discovery for high-risk sites awaiting review, so they stay out of Copilot and organisation-wide search while you work. Permissions stay untouched.
- 5Fix the permissions. Remove "Everyone except external users" where it does not belong, apply restricted access control to sensitive sites, kick off site access reviews with site owners, and assign owners to orphaned sites.
- 6Start on sensitivity labels. Begin with a small, sensible label set for your most sensitive content. Purview's DSPM for AI gives you one-click starting policies and ongoing oversharing assessments.
- 7Verify, release the brake, then roll out. Re-run the reports, confirm the high-risk list is clean, switch Restricted Content Discovery off for remediated sites, and let Copilot loose on data you actually trust.
How long does this take? For a small business with a few dozen sites, the audit and first wave of fixes is typically a week or two of part-time effort. It is not a reason to delay Copilot forever; it is a reason to start the cleanup this week.
One last encouragement: none of this work is wasted if your Copilot plans change. Tidy permissions, clear site ownership, and labelled sensitive data make you safer against phishing, insider mistakes, and plain old human curiosity. Copilot just happens to be the deadline that finally gets it done.
- Microsoft Learn: Microsoft 365 Copilot architecture and how it works
- Microsoft Learn: Get ready for Microsoft 365 Copilot and agents with SharePoint Advanced Management
- Microsoft Learn: Data access governance reports for SharePoint and OneDrive sites
- Microsoft Learn: Restrict discovery of SharePoint sites and content
- Microsoft Learn: Restricted SharePoint Search
Details were current at the time of writing (July 2026). Microsoft's oversharing tooling is evolving quickly, so check the linked pages for the latest guidance.
Knowledge check
5 quick questions. Get 4 right and the module is yours.
1. How does Copilot decide what content it can use in an answer?
2. Why does Copilot suddenly make years-old oversharing a real problem?
3. A site shared with "Everyone except external users" is visible to...
4. What is the right way to use Restricted Content Discovery and Restricted SharePoint Search?
5. What does the mature end-state for Copilot-ready data look like?