What to fix in SharePoint and OneDrive permissions before you switch Copilot on: a pre-flight checklist

The demonstration that ends a Copilot rollout usually happens in week one, and it is never dramatic. Somebody types a question about salary bands, or redundancy, or what the business paid a competitor's former employee, and Copilot answers it accurately from a file that person could always have opened and never would have found.

Nothing was breached. No permission changed. The file had been shared with everyone in the business three years earlier by someone trying to be helpful, and until Copilot arrived, being technically accessible and being findable were two different things. This checklist is the work that has to happen between deciding to buy Copilot and assigning the first licence.

It is deliberately narrow. Frontrow has a separate guide covering how SharePoint permissions break and how to repair them, dealing with inheritance, site types, sharing links and access requests. This one only covers what changes when an AI assistant is about to read the tenant, and it is written in the order the work should be done.

Why Copilot changes the maths on permissions you already had

• Copilot honours existing permissions. It does not escalate, it does not bypass, and it does not see anything the signed-in user could not open by navigating to it. This is true, and it is also the reason the risk gets underestimated.
• What Copilot removes is obscurity. For years, the practical protection on an overshared folder was that nobody knew it was there. A natural-language question over the whole tenant dissolves that protection in one step.
• The exposure is therefore not created by Copilot. It is permissions debt accrued since the tenant was built, all of it called in at once, on the day the licences land.
• Which means the fix is not an AI control. It is a permissions clean-up with a deadline attached, and the deadline is the only genuinely new thing.

Step 1: get a baseline you can put in front of a director

Start with the sites people actually use, not an alphabetical list of everything in the tenant. Microsoft's own Copilot setup guidance begins by exporting the top 100 most used sites from the SharePoint admin centre, and that is the right instinct: usage is a good proxy for what Copilot will draw on.

1. 1Export the most used sites from the SharePoint admin centre and keep the file. It becomes the working list for everything below.
2. 2In the SharePoint admin centre, expand Reports and select Data access governance.
3. 3Run the site permissions snapshot report. It covers every SharePoint and OneDrive site and identifies the sites with the broadest access, including those with very large user counts, external guests, or 'Everyone except external users' permissions.
4. 4Run the site permissions for users report against two or three specific people, ideally including a recent starter and someone in finance or HR. The report lists every site that user can reach, whether directly or through a group. It is the single most persuasive artefact in this entire exercise.
5. 5Run the sensitivity label for files report if labels are in use, so you know where the labelled content actually lives rather than where you assume it lives.
6. 6Save the outputs with a date on them. This is your before state, and you will want it at the ninety-day review.

Step 2: remove 'Everyone except external users' from anything that matters

This is the finding that turns up in nearly every Australian mid-market tenant Frontrow reviews, and it is almost never malicious. It reads like a narrow, sensible option. It resolves to every licensed person in the business.

1. 1Run the 'Shared with Everyone except external users' activity report, which tracks the last 28 days of this kind of sharing and shows where broad internal exposure is being created right now.
2. 2Cross-reference it against the site permissions snapshot, which gives the baseline rather than the recent activity. Microsoft's guidance is to use the two together, and the pairing is what tells you whether a site is a long-standing problem or a new one.
3. 3Sort the results by what the content is, not by how many people can reach it. A site with 400 people on it that holds the staff handbook is fine. A site with 12 people on it that holds performance reviews may not be.
4. 4For each site that should not be organisation-wide, work out who genuinely needs it and grant that through a group. Removing the broad grant without replacing it produces a service desk queue and a rollout everybody resents.
5. 5Deal with the HR, finance, legal and executive sites first, on the basis that these are the sites whose contents make the news.

Step 3: sharing links are permissions, and Copilot honours them

1. 1Run the sharing links activity report. It identifies the sites where users have most recently created links, across Anyone links, organisation-wide links and specific-people links.
2. 2Treat Anyone links as the priority. They work for whoever holds the link, require no sign-in, and the resulting access cannot be attributed to a person in an audit.
3. 3Set the organisation-level default link type to something restrictive before the rollout, then override per site where a genuine need exists. Changing the default changes behaviour at scale in a way that training never will.
4. 4Set expiry on external links so the ones created during the rollout do not outlive it.
5. 5Check the link inventory on the specific sites your Copilot cohort works in every day, because those are the sites Copilot will lean on hardest.

Step 4: OneDrive is the blind spot in almost every readiness plan

Readiness plans concentrate on SharePoint because SharePoint is where the governance controls live. Meanwhile a large share of the business's genuinely sensitive working material sits in OneDrive: the draft restructure plan, the spreadsheet of salaries built for a budget meeting, the client file somebody was working on at home.

• OneDrive sites are in scope for the data access governance reports, so they appear in the site permissions snapshot alongside SharePoint. Do not filter them out.
• Restricted Content Discovery, the control used to hold a site out of Copilot responses while it is reviewed, applies to SharePoint sites only. Microsoft is explicit that it is not supported for OneDrive. There is no equivalent switch, which means OneDrive has to be handled through permissions, labels and behaviour instead.
• Departed staff members' OneDrive content is the recurring one. Where a leaver's files were transferred to a manager, the manager's OneDrive now holds material from a different part of the business, and it will be in scope for that manager's Copilot.
• Sharing from OneDrive is where the Anyone link habit is strongest, because it is the fastest way to get a file to somebody. The organisation-level default link type applies here too.
• Give the Copilot cohort one instruction about their own OneDrive before launch: anything you would not want summarised back to you in a meeting should not be sitting in a folder you have shared with a colleague.

Step 5: sensitivity labels, and the encryption trap

Labels are the control that travels with the content rather than sitting on the site, which makes them the durable answer once a tenant is tidy. They also behave in a way that catches people out on the first Copilot deployment.

• Microsoft Purview documents that where a sensitivity label applies encryption, the user needs the EXTRACT usage right as well as VIEW before an AI app will return the content. A label configured to allow viewing but not extraction will keep the content out of Copilot answers entirely, which reads to the business as Copilot being unreliable.
• That is sometimes exactly what you want. Deciding it deliberately, and telling the affected team, is the difference between a control and a bug report.
• Run the sensitivity label for files report to confirm labelled content is where you think it is. Labelling policy and labelling reality diverge quickly in a business where labels were rolled out and never audited.
• Do not attempt to build a full labelling taxonomy as a prerequisite for Copilot. Two or three labels that are actually applied beat eight that nobody selects.
• Use Data Security Posture Management for AI in Microsoft Purview as the ongoing view of what AI is touching, rather than treating readiness as a one-off project with an end date.

Step 6: restrict discovery on the sites still under review

The permissions review will not finish before the business wants to start. Restricted Content Discovery exists precisely for that gap: it holds a site out of organisation-wide search and Copilot responses while its owners work through access, without changing anybody's permissions.

• Apply it from the SharePoint admin centre under Sites, then Active sites, then the site's Settings tab, by turning on 'Restrict content from Microsoft 365 Copilot'. There is a PowerShell equivalent for doing it at scale.
• A restricted site also loses its AI entry points, so users on that site do not see the Copilot button, the AI actions menus or Create pages with AI. Restricted sites carry a visible Restricted tag.
• Permissions are untouched. Anyone who could open the content before can still open it directly, and the content is not removed from the search index.
• The setting has to propagate across the indexing systems, so it takes time to become fully effective. Do not enable it the morning of launch and assume it has landed.
• Microsoft cautions against using it broadly, because restricting too much starves Copilot of context and produces thin, unhelpful answers.
• Restricted SharePoint Search, the older allow-list approach, is not the tool for this any more. Microsoft has marked it as retiring and states that starting 31 July 2026, new enablement is blocked.

Step 7: ownership, attestation and the sites nobody uses

A permissions clean-up with no owner behind each site is a clean-up that has to be repeated in twelve months. SharePoint Advanced Management includes the controls that make it hold.

• Set a site ownership policy that defines a minimum number of owners or administrators per site and notifies when a site falls below it. Every orphaned site in every tenant began with one owner who was still employed at the time.
• Use site attestation to ask owners to periodically confirm the site is still needed and that its owners, members, permissions and sharing settings are still correct. This moves the access decision to the people who can actually make it.
• Identify inactive sites and notify their owners. Dormant sites still carry permissions, still hold content, and are still fair game for Copilot.
• Use restricted access control to lock a site to a specific group where the content warrants it, rather than relying on nobody stumbling across it.
• Use change history reports to see what has been changed on a site, which is what you will want when somebody asks how a permission got there.

Step 8: agents, because your users are already creating them

The step that did not exist in earlier readiness checklists. Users can now create agents grounded on SharePoint content, and an agent built over an overshared site inherits every bit of that oversharing, then hands it to whoever the agent is shared with.

• SharePoint Advanced Management includes a report identifying recently created agents across SharePoint and OneDrive sites, and which sites have the most agents created on them. Run it, because the answer is rarely zero.
• Treat a site with several agents on it as a high-priority permissions review. Somebody has decided that content is worth querying at scale.
• Decide the position on who may create and share agents before the rollout, and write it into the AI use policy rather than leaving it to a setting nobody has read.
• Restricting content discovery on a site removes the create-an-agent entry points from it, which is a useful side effect while a review is under way.

The Australian bits that decide how hard to push

• Prioritise by personal information, not by file count. Client records, HR files, health information and identity documents are where an Australian business carries obligations under the Australian Privacy Principles, and they are the sites to fix first regardless of how busy they are.
• Remember that unauthorised access, not just external theft, can trigger obligations. Under the Notifiable Data Breaches scheme, an eligible data breach includes unauthorised access to personal information that is likely to result in serious harm, with notification to the OAIC and to affected individuals.
• The OAIC expects a cautious approach commensurate with the risk, and asks organisations to take a privacy-by-design approach including a privacy impact assessment before adopting AI products. A permissions review is the practical half of that assessment.
• Where sites hold information covered by a specific regime, such as health records or financial services obligations, the permissions review is the evidence you will be asked for. Run the reports, keep the exports, date them.
• Australian businesses in construction, professional services and health frequently share sites with clients, subcontractors and consultants. Guests are a legitimate part of how the work gets done, which is exactly why the guest list needs to be reviewed rather than assumed.