Data Access Governance reports: see your SharePoint oversharing before Copilot does

Before you switch on Copilot, there is one question worth losing sleep over: what in here is overshared? Not in theory — in fact. Which sites are open to the whole company. Which files a long-gone contractor can still reach. Which “anyone with the link” shares are still live from a project that ended two years ago. Most admins have no way to answer that, so they cross their fingers and hope.

SharePoint Advanced Management has a set of reports that answer it precisely. They are sitting in your admin center, and almost nobody runs them. They are called Data Access Governance reports, and this is the tour.

Where they are

In the SharePoint admin center, expand Reports and select Data access governance. Everything below lives on that one page. It splits into two kinds of report, and you want both.

Snapshot reports: the baseline

Snapshot reports show your organisation as it stands right now, the day you run them. Four of them, and the first two are the ones that matter most.

Site permissions across your organisation. Microsoft marks this one “recommended,” and it earns it. It analyses every SharePoint and OneDrive site and shows you which have the broadest access, the sites open to thousands of users, to external guests, or to “Everyone except external users.” This is your first look at where the exposure is concentrated. Run it, and the sites that need attention rise straight to the top.

Sites and files shared via special SharePoint groups. This is the one to really pay attention to. Where the report above tells you which sites are overshared, this one tells you exactly which items are effectively public, through the “Everyone except external users” or “Everyone” groups, and how that access was granted. Down to the file. That precision is the difference between “we have an oversharing problem somewhere” and a list you can actually script a cleanup against.

Site permissions for a user. Pick a person; get every site they can reach, and how, whether it was granted to them directly or inherited through a group. This is the question you dread in an access review or a leaver process, and it used to mean an afternoon of clicking. Here it is a report.

Sensitivity labels for files. Which sites hold files carrying a given sensitivity label, so you can confirm the sensitive stuff is where you think it is and protected the way you think it is.

Activity reports: what changed lately

Activity reports cover the last 28 days — the oversharing that happened recently, so you can catch it as it emerges rather than discovering it a year later.

Sharing links. The sites where people created the most new sharing links lately, across all the types: “anyone” links, “people in the organisation” links, and specific-people links. This is oversharing in the act.

Shared with ‘Everyone except external users’. The sites where content was shared with your entire internal organisation in the last 28 days. Broad internal exposure, as it happens.

How to actually use them

The two kinds work together. Run the snapshot reports quarterly to keep a true picture of your baseline exposure. Run the activity reports monthly to catch new risk before it settles in. Start with site permissions across your organisation; it tells you where to look, and everything else drills in from there.

And the reports are not a dead end. From a finding, you act, without leaving the governance tooling:

  • lock an overshared site to a single group with Restricted Access Control;
  • check the change history report to see who opened the access up, and when;
  • or delegate the cleanup to the site owners with a site access review, instead of doing it all yourself.

That is the whole loop: find the oversharing, decide what to do, enforce it. It is Copilot readiness in three steps.

The licensing catch

The full set needs SharePoint Advanced Management, which you have if anyone in the tenant holds a Microsoft 365 Copilot licence, or you have bought the add-on. There is one partial exception worth knowing: an organisation with Microsoft 365 E5 but no SAM can see the activity reports, capped at 10,000 sites, but not the snapshot reports and not the one-click remedial actions.

If none of this is switched on for you

Plenty of organisations have neither a Copilot licence nor the add-on, so this whole page is dark for them. If that is you, the two questions these reports answer, “every site this one person can reach” and “which sharing links are exposing content,” are exactly the two I built free tools for.

The User Access Explorer gives you the site-permissions-for-a-user view. The sharing-link auditor gives you the sharing-links view, and lets you revoke them. Not as polished as Microsoft’s reports, but free, and they answer the question that actually matters before you turn Copilot on: who can already reach what.

August 2, 2026 by Copilot SharePoint Online 0

SharePoint Advanced Management: the features that actually earn their keep

SharePoint Advanced Management has a long feature list. Open the Advanced management page and you will count more than twenty capabilities, which is its own kind of problem: a list that long tells you nothing about where to start. Most of them you will open once, nod at, and never touch again. A handful you will come back to every week. This is about that handful, grouped the way Microsoft groups them: preventing oversharing, controlling sprawl, and keeping an audit trail.

Preventing oversharing

This is the part that matters for a Copilot rollout, and it is where SAM earns most of its keep.

Data Access Governance reports. If you use one thing in SAM, use these. They are a set of reports that show how your content is actually exposed, and each answers a question that used to take a day of clicking:

  • the permission state report is a tenant-wide snapshot of how broadly your sites are shared;
  • the per-user report lists every site a given person can reach and how they got access, which is the question you dread in an access review;
  • the sharing links report surfaces the sites where people created the most new links lately;
  • the sensitivity label snapshot shows how your labels are distributed;
  • and the Everyone except external users report is the single most useful line in here: the content shared with, effectively, the whole company.

These are your oversharing X-ray. Run them before you turn Copilot loose, because they tell you exactly what it is about to surface.

Restricted Content Discovery. Hide a messy site from Copilot and organisation-wide search while you clean it up, without changing anyone’s access. It is the light-touch cover, and I went into it in detail in Restricted Content Discovery vs Restricted SharePoint Search.

Restricted Access Control. The heavier control: lock a site so only members of a specific security group can open it, even if someone else has a direct grant or a sharing link. It is a real access boundary, and it has its own write-up in Restricted Access Control for SharePoint.

Block download. Let people read a site in the browser but not move or download the files out of it. It also covers Teams meeting recordings, which is where a lot of sensitive material quietly walks out.

Site access reviews. This is the one that makes the reports actionable. You found the overshared sites in the Data Access Governance report; now, instead of fixing them all yourself, you delegate the review to the actual site owners, who know whether that access is still needed. It is the difference between a report you feel bad about and a cleanup that actually happens.

Controlling sprawl

Three policies stop your tenant slowly filling up with orphaned and forgotten sites.

The site ownership policy flags sites that have no real owner, or fewer owners than you require, and nudges someone to take responsibility. The inactive site policy finds sites nobody has touched in months and emails the owners to confirm or let go. And site attestations ask owners to periodically confirm that a site is still needed and its access is still right, so the cleanup does not depend on you remembering to chase it.

Run all three in simulation mode first. You want to see what they would flag before they start emailing people.

Keeping an audit trail

Boring until the day you need them, then invaluable.

Change history reports track changes made to individual sites, and to organisation settings, over the last 180 days. When someone asks “who turned sharing back on for this site, and when,” this is the answer. Recent actions is the shorter version: the last changes you made to a site’s properties in the last 30 days, so you can retrace your own steps after a busy afternoon in the admin center.

And a newer one worth a look now that anyone can build one: insights on agents in SharePoint, which show you the agents people have recently spun up across your sites, and which sites are accumulating the most. Agent sprawl is the next version of site sprawl, and it is quietly starting.

Where to start

If the feature list is overwhelming, ignore most of it and start in exactly one place: the Data Access Governance reports. They tell you where your oversharing is. The site access reviews let you delegate the fix. And Restricted Content Discovery or Restricted Access Control hold the line while the cleanup happens. That loop is the whole of Copilot readiness, and it is sitting in your admin center already.

The one thing none of it does is the judgement call underneath it all: deciding who should be able to reach what. SAM will show you the answer and help you enforce it. It will not make the decision for you.

And if you are one of the organisations without a Copilot licence or the add-on, so none of this is switched on for you, that oversharing view is exactly the gap I built User Access Explorer to fill, for free.

August 2, 2026 by Copilot SharePoint Online 0

Restricted Access Control (RAC) for SharePoint: the control that actually locks the door

In an earlier post I said Restricted Content Discovery hides a site from Copilot but does not change who can open it. Turn it on, and anyone with a sharing link still walks straight in. They just will not stumble across the site through search. That is fine when hiding is all you want. When you actually need the door locked, there is a different control, and it is the one people reach for RCD by mistake instead. It is called Restricted Access Control.

What it does that RCD does not

Restricted Access Control, or RAC, restricts a SharePoint site to the members of one or more security groups. Anyone who is not in the group cannot open the site or its content. Here is the line that matters, in Microsoft’s own words: users not in the specified group can’t access the site even if they had prior permissions or a shared link.

Read that again, because it is the whole point. A direct grant does not save you. A sharing link does not save you. If you are not in the control group, the door is shut. That is a real security boundary, which is exactly the thing RCD is not.

The catch in how it lets people in

There is one rule that trips everybody, so learn it first. Being in the control group does not, by itself, let anyone in. To open a RAC-protected site a user needs two things at the same time: permission to the content, and membership in the control group.

Add someone to the group and they still see nothing until they also have permission. Give someone permission and they still see nothing until they are in the group. Both, or nothing.

Copilot honours it too

Copilot and organisation-wide search respect the same policy. A user the door is closed to will not see the site’s content in Copilot or in search either. So RAC quietly gives you what RCD gives you, and then does the thing RCD cannot: it stops the person actually getting in.

Turning it on

You enable it once for the whole tenant, then apply it per site.

Set-SPOTenant -EnableRestrictedAccessControl $true

Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" -RestrictedAccessControl $true
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" -AddRestrictedAccessControlGroups "<group-guid>"

# read it back
Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" |
    Select-Object RestrictedAccessControl, RestrictedAccessControlGroups

You can point up to ten groups at a single site. For a group-connected site, the site’s own Microsoft 365 group is set as the default control group, and you add more from there.

Two things that will bite you

First, RAC locks who can open the site. By default it does nothing about who can share it. Someone inside can still send the content to a person outside the group, and that share works, until you separately turn off outside sharing for RAC sites:

Set-SPOTenant -AllowSharingOutsideRestrictedAccessControlGroups $false

Second, shared and private Teams channels are separate site collections, so a policy on the team’s main site does not reach them. You configure those one by one, as their own sites.

So which one, and when

Restricted Content Discovery is the light touch: keep a messy site out of Copilot’s line of sight while you clean it up, with access left untouched. It is fine to use on many sites during a rollout. Restricted Access Control is the heavy one: this site should only ever be reachable by this group, full stop, and the blocked list is real. You use it on the few sites that genuinely need a locked door, not casually across a tenant, because you are changing who can get in.

Both, though, rest on the same homework: knowing which sites hold the sensitive material, and who actually belongs in the group. RAC will enforce your answer perfectly. It will not tell you the answer. The who-can-currently-reach-what part is still yours, and it is the thing I built User Access Explorer to show.

August 2, 2026 by Copilot SharePoint Online 0

SharePoint Advanced Management: what you get, and whether you already have it

You are reading a Microsoft article about getting ready for Copilot, and it keeps telling you to use SharePoint Advanced Management for this and that. You assume it is one more paid add-on you do not have, and you close the tab. Here is the thing nobody puts in bold: if a single person in your organization has a Copilot license, you already have most of it, and it has been sitting in your SharePoint admin center the whole time.

So let us clear up what it is, and whether you have it, because both are simpler than they look.

What SharePoint Advanced Management actually is

SharePoint Advanced Management page in the SharePoint admin center showing the What's included feature list

SharePoint Advanced Management, or SAM, is a set of governance controls for SharePoint and OneDrive, run from the SharePoint admin center. Microsoft points it at three jobs, in their own plain words: managing content sprawl, managing the content lifecycle, and preventing oversharing.

That last one is why it keeps coming up around Copilot. Oversharing is the thing Copilot makes loud, and SAM is the box of tools Microsoft hands you to deal with it.

The part worth checking before you assume you cannot use it

If your organization assigns even one Microsoft 365 Copilot license to one user, your SharePoint admins get the SAM features that support Copilot. Read that again: not the licensed user, the admins, for the whole tenant. One license trips the switch for everybody who administers SharePoint.

If you have no Copilot anywhere, you can still buy SAM on its own as the Plan 1 add-on, which runs about three dollars per user per month. But most organizations that are even thinking about Copilot have already crossed that line without noticing, and are sitting on a set of governance tools they never opened.

What is actually in the box

You will not use all of it. You will use three or four. The pieces most people came for are the Data Access Governance reports, which are the oversharing reports:

  • a permission-state snapshot across all your sites, so you can see how broadly things are exposed
  • the list of every site a given user can reach, and how
  • a sharing-links activity report, the sites where people created the most new links lately
  • the Everyone except external users report, the single most useful thing in here for a Copilot rollout

Around those sit the controls you act with. Restricted Content Discovery and Restricted Access Control keep a site out of Copilot or lock it to one security group. Block download policies stop files leaving a site. Inactive-site and site-ownership policies handle the sprawl, and change history and recent admin actions cover the lifecycle, so you can see who changed what on a site over the last 180 days.

The one thing the Copilot license does not give you

Almost everything above comes with that one Copilot license. The exception worth knowing is restricting which non-Microsoft apps can create sites, which still needs the Plan 1 add-on. A couple of the reports, like the sensitivity-label snapshot, also want E5. Everything else in the list lands the moment the first Copilot license does.

How to find out what you have

It all lives under Advanced management in the SharePoint admin center. If you have never opened that node, open it. That is faster than reading any licensing table, because it only shows you what your tenant can actually use.

So before you go hunting for a third-party tool to tell you who can reach what, check whether the Data Access Governance reports are already there. If they are, start with them. And if they are not, because there is no Copilot and no add-on anywhere in sight, that same oversharing view is exactly the gap I built User Access Explorer to fill, for free.

August 2, 2026 by Copilot SharePoint Online 0

Check which SharePoint sites are restricted from Copilot with PowerShell

You spent last month turning Restricted Content Discovery on, site by site, to keep the messy ones out of Copilot. Now someone asks a fair question: which sites did we actually restrict? Clicking through Active sites one at a time is not the answer. PowerShell gives you two clean ways to get it, one site at a time and the whole tenant at once, and the tenant one is a command almost nobody knows exists.

First, licensing, so you do not chase an error: Restricted Content Discovery is a SharePoint Advanced Management feature, so these commands need SAM, which you have if anyone in the tenant holds a Microsoft 365 Copilot licence. You also need the SharePoint Online Management Shell and the SharePoint Administrator role.

Check one site

The setting lives on the site as a property called RestrictContentOrgWideSearch. For a single site, read it straight off:

Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" |
    Select-Object Url, RestrictContentOrgWideSearch

The property comes back as a single value: True if the site is restricted from Copilot and organisation-wide search, False if it is not. Simple enough for one site. The problem is the other four hundred.

Check the whole tenant

You could try to loop Get-SPOSite -Limit All and read the property off every site. But Microsoft gives you a purpose-built report for exactly this, and it is the cleaner tool. It runs in three steps, because the report is generated asynchronously. Kick it off:

Start-SPORestrictedContentDiscoverabilityReport

Check on it, and grab the report id once it is ready:

Get-SPORestrictedContentDiscoverabilityReport

Then download it:

Get-SPORestrictedContentDiscoverabilityReport -Action Download -ReportId <ReportGUID>

The download is a report listing every site that has Restricted Content Discovery enabled, one row per site. It lands in the folder you ran the command from. That is your list: every site currently restricted from Copilot, in one file, without touching the admin center.

The half this does not answer

This tells you what you have hidden. It does not tell you what you should have hidden, which is a different question entirely: which sites are actually overshared. Restricted Content Discovery is the cover you throw over a site while you sort the access out; the report above just confirms where the cover is.

Working out which sites need it in the first place, the who-can-reach-what, is the harder half. That is the part I built User Access Explorer to show.

August 1, 2026 by PowerShell SharePoint Online 0

DLP for Copilot: the last lever for keeping content out of Copilot

Everything so far has been about sites and encryption. Restricted Content Discovery hides a whole site from Copilot. A sensitivity label with encryption locks a single file. But two things fall straight through those gaps. The Confidential document that is not encrypted, sitting on a site you never restricted, which Copilot folds into a summary without a second thought. And the user who pastes a customer’s card number into a Copilot prompt to “just check something”. Neither is a site problem, neither is an encryption problem, and this is the control that was built for both: Data Loss Prevention for Copilot.

What it is

It is a Microsoft Purview DLP policy with a location called Microsoft 365 Copilot and Copilot Chat. You will only find it under the Custom policy template, and the moment you switch that location on, every other DLP location in the policy switches off. This one stands on its own.

Keeping labelled content out of answers

The headline job is keeping labelled content out of Copilot’s responses. You add a rule with the condition Content contains > Sensitivity labels, pick your labels, say Highly Confidential and Personal, and set the action to Prevent Copilot from processing content. From then on, Copilot will not pull the contents of a file carrying those labels into a response.

Here is the part that makes it different from everything before it. The trigger is the label, not the encryption. So the unencrypted Confidential file, the one the EXTRACT usage right could never touch because there was no encryption to hang a right on, is now excluded all the same. And Copilot stays honest about it: the item can still appear in the response’s citations, so the user sees that something was deliberately held back rather than quietly missing.

Three more things the same location does

Blocking labelled files is what most people come for, but the Copilot location does three more jobs worth knowing.

It can stop a prompt in its tracks when the user types a sensitive information type into it, a credit card or a passport number, so Copilot simply refuses to answer. It can keep those same sensitive types from being sent out to external web search, while still answering from your internal data. And, in preview, it can drop emails from external senders out of Copilot’s grounding entirely, which is a quiet but real defence against a prompt injection arriving by email.

What will trip you

A few things bite if you do not know them. You cannot put a sensitive-information-type condition and a sensitivity-label condition in the same rule; make two rules in the one policy instead. The email coverage only reaches messages from 1 January 2025 onward, and calendar invites are not covered at all. Changes take up to four hours to show in Copilot, so do not test it in the first five minutes. And there is a simulation mode, which you should absolutely use before you turn any of this on for real.

Where it sits, and the one thing it still does not do

So now you have the whole set. A label with encryption stops Copilot reading a file. Restricted Content Discovery hides a site. Restricted Access Control locks a site to a group. DLP is the finest-grained of the four, the only one that works off the label without needing encryption, and the only one that acts on the prompt itself in real time.

One thing has been true of every single one of them, and it is worth saying plainly. None of these change who can open the file. A DLP rule stops Copilot summarising the document; the person it was overshared to can still open it and read every word. The controls decide what Copilot may do. They do not decide who has access. That question, the one sitting underneath all four of these posts, is still yours, and it is what I built User Access Explorer to answer.

August 1, 2026 by Copilot Microsoft 365 0

Does Microsoft 365 Copilot copy your data to answer you?

Propose Copilot to a security-minded colleague and you get the same question within about thirty seconds. “So it makes a copy of all our data? Where does that copy live? Who else can see it?” The mental picture is Copilot hoovering up every file in the tenant into some giant AI brain in the sky. The reality is a lot more boring, and a lot more reassuring. Here is what actually happens.

The short answer

Copilot does not make a copy of your documents to answer you. It reads your content in place, through Microsoft Graph, the same plumbing that already powers search across Microsoft 365. When you ask something, it goes and finds the relevant material you already have access to, uses it to answer, and moves on. Your files stay exactly where they are.

But it does build an index, so isn’t that a copy?

This is the part that trips people, because it is technically true that Copilot builds something out of your data. It is called the semantic index, and the word “index” is the one that matters. It is not a copy of your files. It is a mathematical representation of them.

Microsoft turns your text content into vectors  numbers that capture meaning  so that “the vendor did great design work” and “the supplier’s artwork was excellent” land close together even though they share no words. That is what lets Copilot answer a fuzzy question well. But a pile of vectors is not your document. You cannot reassemble the payroll spreadsheet from the index any more than you can rebuild a song from its search tags.

And that index never leaves your tenant. In Microsoft’s own words, the data generated by indexing remains within your company’s tenant. The user-level index sits where your mailbox lives; the tenant-level index sits in an isolated container in your own tenant’s region. It doesn’t even count against your storage quota. And it honors the same permissions as everything else, so it only ever helps surface content you were already allowed to open.

What actually happens when you ask

Here is the full sequence when you type a prompt, straight from Microsoft’s documentation:

  1. Your prompt goes from the app to Copilot.
  2. Copilot checks Microsoft Graph and the semantic index for relevant, permission-trimmed context, and appends what it finds to your prompt.
  3. That grounded prompt goes to the language model.
  4. The model’s response comes back.
  5. Copilot runs a post-processing pass, adds citations, and returns the answer to your app.

The content pulled in at step 2 is used to answer, and then it is done. It is grounding for that one question, not a copy squirrelled away somewhere.

So what is stored?

Something is kept, and it is worth being precise about what. Copilot stores the conversation — your prompt and its response, with citations — as your Copilot activity history. That is encrypted, stored alongside your other Microsoft 365 content, discoverable and retainable through Microsoft Purview, and you can delete it yourself from the My Account portal.

Read that again: what is stored is the chat, not a second copy of your source files. The spreadsheet Copilot cited still lives in its one place in SharePoint. The record is simply that you asked about it and what Copilot said back.

Three things that usually settle the room

  • None of it trains the AI. Your prompts, your responses, the data pulled from Graph, and the semantic index itself are not used to train the foundation models. Microsoft states this flatly, in more than one place.
  • No human is reading it. Azure OpenAI has an abuse-monitoring feature that includes human review of content. Microsoft 365 Copilot has explicitly opted out of it.
  • It stays in your boundary. The data honors your tenant isolation and residency commitments, including the EU Data Boundary for EU customers.

So where is the actual risk?

If the data handling is this clean, what is left to worry about? The one thing all of it was careful to preserve: permissions. The index respects them. Grounding respects them. Copilot only ever surfaces what a person could already open.

Which means Copilot was never going to leak your data by copying it. It will, however, faithfully surface anything you already overshared, to whoever you overshared it with, the moment they ask. You can pull a genuinely sensitive site out of the index — by turning off its search visibility or excluding it with a DLP policy — but notice what that is: hiding, not fixing. The people who could already reach it still can.

That is the whole story. Copilot does not copy your data. It indexes it as vectors inside your own tenant, searches it in place, shows each person only what they could already access, keeps the conversation rather than your files, and trains nothing. The question worth losing sleep over was never where your data goes. It is who can already reach it — and that part is still yours to answer. It is what I built User Access Explorer to show.

Sources

Every claim above comes from Microsoft’s own documentation. If you want to read the primary material:

August 1, 2026 by Copilot Microsoft 365 0

Microsoft 365 Copilot vs Glean: the permissions question that actually decides it

Sooner or later, someone in a Microsoft shop asks it out loud: should we just buy Glean instead of turning on Copilot? Usually the thinking is that one of them must be safer with company data than the other. It is a fair question, and the honest answer is not the one either vendor’s deck gives you.

Both are enterprise AI that answers questions over your own company content. Microsoft 365 Copilot does it from inside Microsoft 365, grounded on your SharePoint, OneDrive, Exchange and Teams, reaching outside through Graph connectors. Glean does it across the whole app estate, pulling from Google Drive, Slack, Salesforce, Jira, Confluence, Microsoft 365 and the rest through its own connectors. One is deep in one place. The other is broad across many. Hold that thought, because it is the real difference and we will come back to it.

The thing they do identically

First, the part people get wrong. Both are permission-aware. Neither invents access.

Glean pulls the permission map, the access-control list, from every source it connects to, and filters what it retrieves down to what you personally can see. In their own words, if you do not have access to a document in Google Drive or a channel in Slack, it never appears in your Glean results and never lands in an answer it writes for you.

Copilot behaves the same way inside Microsoft 365. Every prompt runs in your security context. If you cannot open a file in SharePoint, Copilot will not summarise it for you. It only ever surfaces what you already had permission to reach.

So on the question people actually lose sleep over, “will it hand data to someone who should not see it”, both give the same answer: no, not beyond what your permissions already allow.

The mess both of them inherit

And there is the catch neither deck leads with. Permission-aware cuts both ways. It faithfully reproduces your access model, mess and all.

A document shared with Everyone is a document both of them will happily hand to everyone, because everyone genuinely has permission. A folder a departing employee opened up three years ago is fair game the moment somebody asks the right question. Neither tool overshares. Your tenant already did. The assistant just takes what was buried under a thousand folders and makes it instantly reachable, in plain language, to anyone who thinks to ask.

This is why switching from one to the other fixes nothing about safety. If your SharePoint is overshared, Copilot surfaces it. If your Drive and Slack are overshared, Glean surfaces it. The assistant is only ever as clean as the permissions underneath it, and picking a different assistant does not clean them.

 

So what actually decides it

If safety is a wash, two things are left, and these are the ones to argue about.

Reach. Copilot is native and deep in Microsoft 365, so if that is where your knowledge lives, it needs nothing extra to be useful, with Graph connectors extending it outward when you need them. Glean’s whole pitch is breadth: if your organisation’s knowledge is scattered across a dozen SaaS apps, Glean was built to index all of it in one place and answer across the lot. A heavily Microsoft shop leans one way. A best-of-breed-SaaS shop leans the other. This, not security, is the honest deciding line.

The governance around it. Microsoft does not just hand you Copilot, it hands you the machinery to manage the oversharing Copilot exposes: Purview for data loss prevention and sensitivity labels, SharePoint Advanced Management for Restricted Content Discovery, Restricted Access Control, and the Data Access Governance reports. Glean brings its own model, single-tenant connectors, permission sync kept current across every app, least-privilege enforcement, and zero-retention agreements with the model providers so your data is never used for training. Both are serious. They are serious in different shapes: one is a governance stack you assemble around the assistant, the other is a posture baked into the platform.

The honest verdict

So it is not “which is safer”, because on the answer that matters they behave the same. It is “where does your knowledge actually live, and how much Microsoft governance do you already own”. A Microsoft-centric org already holding Purview and SharePoint Advanced Management has most of the toolset and the native depth in hand. An organisation whose real knowledge is spread across non-Microsoft SaaS has a genuine case for Glean’s breadth.

But the decision underneath both, the one that actually determines whether either is safe to switch on, is the same no matter which logo you pick. They surface what people can already reach. So the work is not choosing the assistant. The work is fixing the oversharing first, so that when you do turn one on, it has nothing embarrassing to find.

That part, the who-can-currently-reach-what across your Microsoft estate, is what I built User Access Explorer to show. Whichever assistant you land on, do that first.

July 31, 2026 by Copilot Microsoft 365 0

Sensitivity labels and Copilot: which ones actually keep content out

A user opens a protected document, reads it without any trouble, and then asks Copilot to summarise it. Copilot refuses. It just hands back a link to the very file they already have open. So they raise a ticket saying Copilot is broken. It is not broken. It is doing one thing right that almost nobody knows about.

How Microsoft 365 Copilot behaves around sensitivity labels comes down to a single usage right you have probably never looked at, called EXTRACT. Once that one idea lands, the rest of it stops being confusing.

VIEW lets you read. EXTRACT lets Copilot summarise.

When a sensitivity label applies encryption, it grants each person a set of usage rights. Two of them matter here. VIEW is the right to open the file and read it. EXTRACT, which shows up in the Purview portal as “Copy and extract content” and carries the friendly name Copy, is the right to copy text out of it.

Copilot needs EXTRACT. Not VIEW, EXTRACT. In Microsoft’s own words, if the content grants a user VIEW but not EXTRACT, Copilot will not summarise it and can only point to it with a link.

So the user in that ticket had VIEW and not EXTRACT. They could read the file with their own eyes all day. Copilot, which works by pulling the text out, was never allowed to. Same file, same person, two different answers, and both are correct.

One exception is worth knowing: whoever applied the encryption always has EXTRACT, because they own it. So a file you protected yourself will always come back to you in Copilot. The restriction is for everybody else.

So here is the switch

Turn that around and you have the cleanest control you will find. If you want a class of content genuinely out of Copilot’s reach, use a sensitivity label that applies encryption without the Copy (EXTRACT) right. People who need to can still open and read. Copilot cannot summarise it, quote it, or carry the text into anything it generates. You have not taken access away from anyone, you have taken it away from the machine.

The stronger settings go further. Content labelled with user-defined permissions is off-limits to Copilot and agents entirely while it sits unopened in SharePoint or OneDrive. And Double Key Encryption, the one meant for your most sensitive material, Copilot cannot touch at all.

Now the trap

Here is where people get a false sense of safety. You put a Confidential label on the site, assume everything inside it is now hidden from Copilot, and move on. It is not. A label applied to a container, a SharePoint site or a Microsoft 365 group, is not inherited by the files inside it. Copilot does not see the site’s Confidential label on the document, and the document carries no protection of its own. As far as Copilot is concerned, the label on the site does nothing at all for the files.

If you want the files protected, the label has to be on the files. The site label is for the site.

What Copilot writes carries the label forward

There is a nice half to this. When Copilot builds new content out of labelled sources, it inherits the highest-priority label among them. Summarise three documents where the most sensitive is Confidential, and the summary itself comes out Confidential. The protection follows the content into whatever Copilot produces, which is exactly the behaviour you would want.

How to check one file in ten seconds

If you are ever not sure whether a document you can open is also readable by Copilot, open it in the Windows Office app and add Permissions to the status bar. Click the icon next to the label name, look at My Permission, and read the value for Copy. Yes means EXTRACT, which means Copilot can use it. No means it cannot.

The one thing labels do not do

Labels decide what Copilot is allowed to do with a file. They do not decide who can open it. A document shared with Everyone is still shared with Everyone; the label only stops Copilot from summarising it for them. So a label is a good lever, and it is not a substitute for fixing who has access in the first place. If you also want to block Copilot from summarising specific labelled files without touching their encryption, a Purview DLP policy for the Copilot location can do that, but the EXTRACT right is the idea that explains everything else.

The access question is still yours to sort out. If that is where you are stuck, I wrote a free tool for it: User Access Explorer.

July 31, 2026 by Copilot Microsoft 365 0

Restricted Content Discovery vs Restricted SharePoint Search: what actually hides content from Copilot

An admin switches on Restricted SharePoint Search to keep Copilot away from the messy sites nobody has cleaned up yet, tells the boss it is handled, and one week later the help desk is full of “I cannot find anything in search now” tickets. Two features sound like they do the same job, and picking the wrong one is exactly how you land in that week.

So there are two of them: Restricted SharePoint Search and Restricted Content Discovery. Both keep content out of org-wide search and out of Microsoft 365 Copilot. But they are not the same tool, they are not meant for the same job, and as of this month one of them is on its way out.

Restricted SharePoint Search: a blanket over the whole tenant

Switch it on, and org-wide search and Copilot see only the sites you put on an allowed list (up to 100), plus each user’s own OneDrive, the sites they visit often, and the files that were shared with them or that they recently touched. Everything else drops out of tenant-wide discovery. Not deleted, not locked, just invisible to search.

Microsoft has always called this a temporary measure, and now they are ending it. From 31 July 2026, you can no longer turn Restricted SharePoint Search on for the first time, and the official word is to move to Restricted Content Discovery instead. If you already have it on, the plan is the one it always was: use it to buy time, fix the oversharing underneath, and then switch it off.

So it was never meant to stay. A tenant where search only ever returns 100 sites is a tenant where people quietly stop using search, and Microsoft’s own advice is to disable it once you have cleaned up.

Set-SPOTenant -EnableRestrictedSharePointSearch $true

The allowed list, up to 100 sites, you curate with Add-SPOTenantRestrictedSearchAllowedList, Remove-SPOTenantRestrictedSearchAllowedList and Get-SPOTenantRestrictedSearchAllowedList, passing a site URL or a CSV of them.

Restricted Content Discovery: a switch on one site

This is the one Microsoft is now pointing everyone to. It is per-site. Turn it on for a site, and only that site’s content drops out of org-wide search and Copilot. Every other site stays exactly as it was. No allowed list, no tenant-wide blanket, just a flag on the sites that really need it.

Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" `
    -RestrictContentOrgWideSearch $true

# read it back
Get-SPOSite -Identity "https://contoso.sharepoint.com/sites/Finance" |
    Select-Object Url, RestrictContentOrgWideSearch

There is a licensing catch. Restricted Content Discovery is a SharePoint Advanced Management feature, so you need SharePoint Advanced Management to use it, which you get either by having Microsoft 365 Copilot licensed (even a single user counts) or by buying the add-on. Restricted SharePoint Search needed no such thing, and that is the main reason the blunt one was what most tenants reached for first. Now that it is retiring, the licensed per-site switch is what is left.

The difference that actually matters

So here is the whole thing in one line. Restricted SharePoint Search decides what is discoverable and hides everything else. Restricted Content Discovery decides what is not discoverable and leaves everything else alone. One is opt-in for the entire tenant, the other is opt-out for a handful of sites.

The blanket was for the panic phase, when Copilot is going live tomorrow and you have audited nothing. The per-site switch is for afterwards, when you already know which three sites hold the sensitive material and you want them out of Copilot without breaking search for everybody else. Microsoft has now made that choice for you: the blanket is being taken away, and the switch is what remains.

What neither of them does

Now the part people miss, and Microsoft is blunt about it in its own docs: neither feature is a security boundary, and neither changes who can open the content. That Everyone-except-external claim on the finance site is still sitting there. That organisation-wide sharing link still works. Anyone who already had access still walks straight in, search inside the site still finds everything, and while the blanket is on, Copilot will still surface a site to a user who recently visited it. You have not fixed the oversharing at all. You have only stopped Copilot from putting a spotlight on it in front of the whole company.

That is a reasonable thing to do while you clean up. It is a bad thing to mistake for the cleanup. The access is the real problem; discovery is only the symptom that Copilot made loud.

So the order is simple, and it is the order Microsoft itself recommends. Find the oversharing first, decide which sites genuinely need to stay hidden, and use Restricted Content Discovery on those. These controls only buy you the time to do it. They do not do it for you.

I wrote a free tool for the finding-the-oversharing part, if that is where you are stuck: User Access Explorer.

July 31, 2026 by Copilot SharePoint Online 0

Start Here

PnP PowerShell for SharePoint Admins
The scripts, in reading order

What Copilot Chat (Basic) Can Do
Where the free tier stops

About this site
Who writes it and how it is tested