SharePoint permissions to fix before you turn on Microsoft 365 Copilot

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.

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.

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.

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.

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.

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 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 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.

The right 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.

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 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.

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 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 law firm, and the staff portal we built for Stone Leaf Capital, an AFSL holder in funds management and corporate advisory, both sit in settings where somebody is entitled to ask who could reach a record and to be shown the answer. A Copilot rollout puts the same question to a business, and the tenant either produces the evidence or it does not.