Black Shard

Insights28 July 2026

What to fix in SharePoint before you turn on Microsoft 365 Copilot

Copilot grants nobody new access and removes the effort of finding, which turns old SharePoint permission defects into visible answers. The signals that mark a risky site, the difference between containing an exposure and fixing it, and the stopgap that can no longer be switched on after 31 July 2026.

A wall of steel filing cabinet drawers with three drawers pulled open, lit cold with a cyan accent on dark slate

What Microsoft 365 Copilot actually reads

Copilot answers by grounding. It takes the prompt, retrieves relevant material from Microsoft Graph and the semantic index inside your own tenant, enriches the prompt with what it found, and sends that to the model. The retrieval step runs in the security context of the person who typed the prompt, and results are trimmed to what that account could already open. Microsoft's documentation is direct about this: Copilot presents only data the individual can access, using the same access controls as the rest of Microsoft 365, and the semantic index honours the user identity-based access boundary during grounding.

That design decision is what makes a rollout a permissions problem. Copilot widens nobody's access; what it removes is the effort of finding, and effort was the only thing standing between a bad grant and its consequences. Before the rollout, an over-permissive site was protected by obscurity: staff navigated to the sites they already knew about, tenant-wide search was rarely used, and nobody typed a question like which staff are on performance management.

The reach is wider than SharePoint. Mail, chats, meeting content, OneDrive files and external material brought in through a Microsoft 365 Copilot connector all carry their own access control and all become reachable through the same chat box. SharePoint is where the decision gets made, because that is where the mass of shared organisational content sits and where broad grants accumulate fastest. One piece of assurance is worth having ready for the same conversation: prompts, responses and the data reached through Microsoft Graph are not used to train the foundation models.

The permission defects that predate the rollout

Everyone except external users is a built-in SharePoint group that contains every internal account, including everyone hired after the grant was made. Content lands in it two ways. A site set to public puts the group into the site membership, so the whole site becomes readable by the organisation. Separately, an individual file, folder or list can be shared to the group through the people picker while the site around it stays private. The second case is the one that survives reviews, because the site properties look correct and only the item is public.

Sharing links accumulate underneath that. Anyone links are anonymous by design, work for whoever ends up holding them, and cannot be attributed to a person after the fact. Organisation-wide links work for any internal account that receives a forward, which is most of them within a few hops. Microsoft's own readiness guidance states plainly that SharePoint sets sharing to the most permissive option by default, so a tenant nobody has deliberately tuned sits at the permissive end by construction and not by anyone's decision.

Broken permission inheritance is the structural version of the same problem. A library, folder or single item that stopped inheriting from its parent carries an access control list of its own that no parent-level review will ever touch. Combine that with a large audience and you get the classic surprise: a site whose top-level permissions look defensible and a folder three levels down that half the company can read. Add ownerless and inactive sites and nobody is left who can answer whether a grant is still appropriate, while the content stays perfectly retrievable.

Stale content fails differently. A confident answer drawn from a superseded policy or an unadopted draft looks exactly like a good answer, and an unlabelled site holds no classification that any downstream control can act on.

Which SharePoint sites are actually high risk?

Triage has to be report-driven. A tenant with a few thousand sites cannot be assessed by opening site settings one at a time, and the answer changes weekly. The signal that matters is overlap: a site carrying one risk marker is worth a look, and a site carrying three is where a Copilot rollout produces its first incident. Sensitive content with Anyone links, a public site with no owner, and a large audience sitting over broken inheritance are the combinations to pull to the top.

Know what each report is for before you read it. The snapshot reports in the SharePoint admin centre describe the current permission structure across every site and are worth running quarterly. The activity reports cover the last 28 days and rank the busiest sites, which catches new oversharing as it happens without ever amounting to a full inventory. Two counting rules decide whether you read them correctly. The total permissioned users figure in the site permissions report expands every group and then removes duplicates, while the per-item counts a site owner sees in an access review are not deduplicated, so one person holding both group access and a sharing link is counted twice.

The second rule matters more. Creating a sharing link or granting to Everyone except external users does not move the permissioned-user count at all, because that is potential exposure and only becomes counted exposure once somebody uses it. A site can therefore report a modest audience and still be readable by the entire organisation, which is why the sharing and group signals have to be read alongside the count.

Risk signalHow to detect itFirst action
Everyone except external users sits in the site membership, so the site is organisation-readableSite permissions snapshot report, then the EEEU activity report at site scopeConfirm the site is meant to be readable by everyone; if not, remove the group from the membership and re-scope
Individual files or folders shared to everyone inside an otherwise private siteEEEU activity report at item scope, covering the last 28 daysSend the site owner a site access review, which lists the affected items and gives them Manage access on each one
Anyone links on a site holding sensitive contentSharing links activity report, which ranks sites by links created in the last 28 days by link typeExpire or revoke the links, then set the site default link type to specific people
Organisation-wide links forwarded well past the intended audienceSharing links activity report, read by link type and not by totalChange the site default sharing link type and reissue access to named people
Broken permission inheritance sitting under a large audienceSite permissions snapshot report and the permissioned-user count per scope in a site access reviewRestore inheritance where the content allows it, otherwise record the exception against a named owner
Ownerless or inactive sitesSite ownership, inactive site and site attestation policies under site lifecycle managementAssign an accountable owner, or archive the site, which puts its content beyond reach until someone reactivates it
Site carries no sensitivity labelSensitivity label snapshot reportApply a container label so the site inherits a sharing and access posture instead of the tenant default
Sensitive content with weak protection on itPurview data risk assessments in Data Security Posture Management, which run weekly by default over the top 100 sites by usageLabel and encrypt, then verify which usage rights the label actually grants

SharePoint oversharing signals, where each one shows up, and the first move

Containment and remediation are different jobs

Two controls in this area sound alike and do fundamentally different things, and confusing them produces a rollout that reads as complete and is not. Restricted Content Discovery changes what is discoverable. Restricted Access Control changes who can get in at all. Only the second is an access boundary, and only the second survives a question from an assessor about who can reach the data.

Restricted Content Discovery is a site-level property. Turn it on and the site's content stops appearing in organisation-wide search results and in Copilot responses, the AI entry points disappear so users lose the Copilot button, the AI actions menus and the ability to build agents over that content, and a restricted marker appears against the site. Permissions do not move at all. Anyone who already had access can still open the file by following a link or navigating to it, search that originates from inside the site is unaffected, and asking Copilot to summarise a document already open still works. The content also stays in the search index, which is why Purview capabilities such as eDiscovery and auto-labelling keep working. Those properties are correct behaviour, and they are also the proof that this is a review-window control and not a security control. It applies to SharePoint sites only, so OneDrive is outside its scope entirely.

Restricted Access Control works on membership. You nominate Microsoft Entra security groups or Microsoft 365 groups, up to ten per site, and a user outside those groups cannot open the site or its content even if they hold a permission or a sharing link. Two conditions now have to be true at once: the person is in the control group and the underlying permission exists. Adding someone to the group does not grant them permission by itself, which is the detail most teams get wrong on the first attempt. It also does not travel down a team's structure, so shared and private channel sites are separate site collections and need the policy applied to each.

Both changes travel through the search index and neither is immediate. Restricted Content Discovery on a site above roughly half a million items can take more than a week to reflect fully, and access restriction latency scales with item count the same way. Schedule the containment window before licences are assigned, and verify the state afterwards.

ControlWhat it changesWhat it leaves aloneIs it an access boundaryMeant to be permanent
Restricted Content DiscoveryRemoves the site from organisation-wide search and Copilot responses and strips AI entry points from the siteSite and item permissions, direct access by anyone who has it, in-site search, and the search index itselfNoNo, it is explicitly a control for the review window
Restricted Access ControlAdds a group membership condition on top of permissions for the whole siteThe underlying item permissions, which still have to be rightYesYes, where a site genuinely belongs to a defined group
Restricted SharePoint SearchLimits organisation-wide search and Copilot to an allow list of up to 100 sitesPermissions, and content the user owns or recently used, which still comes backNo, Microsoft states it is not a security boundaryNo, new enablement is blocked from 31 July 2026
DLP policy scoped to the Copilot locationStops labelled items being used to ground or summarise a responsePermissions, and the citation list, where the item can still appearNoYes
Sensitivity label that applies encryptionEnforces usage rights on the file wherever the file travelsWhere the file is stored and who can see that it existsYesYes
Correcting the permissionRemoves the grant that should never have existedNothing else, which is why it is the only action that closes the findingYesYes

Copilot oversharing controls: what each one moves and what it leaves alone

Restricted SharePoint Search is retiring on 31 July 2026

Restricted SharePoint Search is the allow-list approach: an administrator curates a list of up to 100 sites that have been permission-checked, and organisation-wide search and Copilot are limited to those sites. It bought organisations time, and plenty of rollout plans still rest on it. Microsoft's own documentation says it is not a security boundary, does not change permissions on any site, and is not scalable for long-term use, which is unusually blunt language for a shipped feature.

It also leaks by design, and the leak is the part people miss when they present the plan internally. Content a user owns, has recently accessed, or that was shared with them through Teams or Outlook still comes back in their results even when the site is nowhere near the allow list. The control narrows exposure to content a person has never touched and does nothing for content they touched once, which buys a review period and makes a poor permanent position.

The date now matters. From 31 July 2026 new enablement is blocked, so if the setting is not already on in your tenant it is not an option to plan around. If it is on, the position has an end date and needs replanning onto Restricted Content Discovery for the sites still under review, sensitivity labels for content that needs protection wherever it goes, and data loss prevention scoped to the Copilot location.

Plan the switch-off as a change, because it behaves like one. On the day the allow list stops applying, staff results in both search and Copilot change with nothing else in the tenant having moved, which is why Microsoft's guidance is to notify agent owners and the IT team first. Expect the first week of tickets to be people finding content they could always have opened.

What sensitivity labels and DLP actually stop Copilot doing

A sensitivity label is the only control here that travels with the file. Where a label applies encryption, Copilot checks the usage rights granted to the user and returns nothing unless the user holds both VIEW and EXTRACT, the usage right whose common name is Copy. A label configured so that readers cannot copy will keep the content out of a Copilot answer while leaving the person perfectly able to open the document themselves, which is worth confirming on a real file instead of inferring it from the label name.

Several details around that behaviour catch teams out. Whoever applied the encryption is the rights management owner and always holds every usage right, so their own content always comes back to them regardless of the restrictions others face. Content protected with double key encryption cannot be reached by Copilot at all. Labels that use user-defined permissions block agents from reading the file. Labels applied to Teams meetings and chats are not currently recognised, so that content returns without its label. And unless sensitivity labels are enabled for SharePoint and OneDrive, the encrypted files Copilot can act on are limited to data in use inside Office apps on Windows.

Data loss prevention scoped to the Microsoft 365 Copilot and Copilot Chat location is the second durable layer. It can prevent items carrying nominated sensitivity labels from being processed into a response, block nominated sensitive information types from being submitted in a prompt at all, block external web search as a grounding source when a prompt contains those types, and exclude externally received email from grounding, which cuts prompt-injection surface. The prompt-blocking and external-email controls are still in preview, so check that both have reached your tenant before a runbook depends on them.

Three limits belong in that runbook. An excluded item can still appear in the citations of a response even though its content was never used, so a citation list is not evidence that content was read. A file a user uploads directly into a prompt is not inspected, because the policy only evaluates the text typed into the prompt. And enforcement is not instant: policy changes take up to four hours to appear in the Copilot experience, and inside Word, Excel and PowerPoint the policy is evaluated when the file opens, so a label applied mid-session takes effect at the next open.

What did Copilot surface, and to whom?

Every interaction writes an audit record, and the record is better than most teams expect. The operation is CopilotInteraction, and each record carries an AccessedResources property listing every file, site or message Copilot read while answering, with the site URL, the resource name and type, the action performed, and the sensitivity label identifier where the item carried one. Another property identifies the host application, so you can tell a chat in the Copilot app from an interaction inside Word or Teams.

Three things have to be settled before licences are assigned, because none of them backfill. Confirm that unified audit log ingestion is actually on for the tenant, since assumption is how organisations discover during an investigation that it was disabled years ago. Confirm who holds the Audit Logs or View-Only Audit Logs roles that permit searching and exporting records, so the investigation does not stall on access. Confirm retention against the licences your users actually hold: audit records are kept for 180 days by default, records for Microsoft Entra ID, Exchange, SharePoint and OneDrive activity by E5-licensed users are kept for a year under the default policy, and anything beyond that needs a retention policy created deliberately.

The question a board asks after an incident is narrow and answerable if that groundwork exists: which accounts asked, what Copilot read in order to answer them, whether any of it carried a sensitivity label, and across what period. Settle one point in advance so nobody promises more than the record holds. The audit entry captures the interaction and the resources touched, while the prompt text itself is reached through a different path, either content search or the AI interaction events in Data Security Posture Management for AI.

Sequencing a rollout you can defend

The honest order is find, contain, remediate, then remove the containment. Most rollouts that go wrong stopped at contain and reported completion, which is an understandable mistake because a contained tenant looks finished from the admin centre while the grants underneath it are unchanged. This is a permissions programme that an AI rollout happened to trigger, and it should be resourced as one.

The remediation half cannot be run centrally, and Microsoft has built the tooling on that assumption: administrators are kept out of file-level and item-level detail for compliance reasons, so the review has to be delegated. A platform administrator can see that four hundred people have access to a folder and cannot decide whether that is correct, because only the site owner knows what the content is and who needs it. Site access reviews put the decision with the person who can make it, up to 100 sites at a time from the report view and more through PowerShell. Set an expiry on every containment decision at the moment you make it, so a temporary control cannot quietly become permanent.

  • Run the content management assessment and the snapshot reports before you change anything, and keep the output, because you will be asked later what the tenant looked like at the start.
  • Contain the overlap set first, meaning the sites where more than one risk signal lands, and allow index propagation time before you measure whether the containment worked.
  • Push remediation to site owners through site access reviews, with a due date and a named executive who chases the ones that do not come back.
  • Re-run the reports, confirm the signal has actually cleared, then lift the containment site by site and watch what changes in search and Copilot after each one.
  • Re-run the activity reports monthly and the snapshot reports quarterly, because every activity report only covers the previous 28 days.

Where this lands under Australian law

Australian Privacy Principle 11 requires an entity to take steps that are reasonable in the circumstances to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. A permission structure that lets every employee read the HR drive is a control question under APP 11 whether or not anyone has actually read it, and the fact that the system granted the access does not settle whether the organisation ever authorised it. The OAIC's own guidance lists unauthorised access to personal information by an employee as an example of a data breach.

That connects the rollout to the Notifiable Data Breaches scheme more directly than most project plans acknowledge. An eligible data breach has three elements: unauthorised access to or disclosure of personal information the entity holds, a likelihood of serious harm to the individuals concerned, and an inability to prevent that likely harm through remedial action. An internal exposure can satisfy the test on its own facts. Where it is unclear, the entity must assess, and section 26WH(2) of the Privacy Act gives 30 calendar days from becoming aware of the grounds for suspicion. Assessing means answering who reached what and when, which returns you to whether auditing was configured before the licences were assigned.

The practical framing for a risk owner is narrower than the question they usually get handed. The decision does not turn on whether Copilot is secure as a product. It turns on whether the organisation can state, with evidence and not assertion, who can currently reach what, and can produce a record of what was surfaced and to whom. Content held under legal or clinical obligation raises the stakes further, because a single retrieved paragraph can carry identified personal information into a chat window that was never in scope for it.

How we run this before the licences move

We treat a Copilot readiness engagement as an access review with a deadline attached, and run it inside the same Microsoft 365 and Entra ID security work we do for tenants with no AI plans at all. Identity comes first, because conditional access, administrative roles and application consents decide who is inside the tenant before anything decides what they can read. Then the content posture: the reports run and interpreted, a triage list ordered by overlapping signals, and a written containment decision for each site carrying an owner and an expiry date.

The auditing position gets settled in the same pass, before licences move, because it is the only part that cannot be fixed retrospectively. That means confirming ingestion, roles and retention against the licences the organisation actually holds, and writing down which questions the resulting records can answer and which they cannot. Where the governing decisions belong at executive level instead of inside IT, that runs through our vCISO advisory, which is also where the rollout gate sits.

We work this way for the same reason we build the systems we build. The operations and compliance portal we run for GRM LAW, a Brisbane law firm, and the staff portal we built for Stone Leaf Capital, an Australian capital-markets firm, both sit in settings where somebody is entitled to ask who could reach a record and to be shown the answer. Our approach and trust pages set that posture out in full. A Copilot rollout puts the same question to a business, and the tenant either produces the evidence or it does not.

Put a security lead at your table.

Australia-wide, from our Brisbane head office. Someone will contact you as soon as possible.

Open a briefinfo@blackshard.com.au