Copilot did not create your oversharing problem. It made it searchable, and it gave the search box to everyone with a licence. That distinction decides who owns the fix. If you treat oversharing as a Copilot problem, you will buy a Copilot-shaped control, switch it on broadly, and then spend the next two quarters wondering why the answers got worse. If you treat it as an information management problem that Copilot exposed, you end up doing the unglamorous work that was overdue before anyone mentioned AI.
Nothing leaked. It was found
The pattern is the same everywhere I have seen it. A site is created for a project. Permissions are set to everyone in the organisation, because that was the fastest way to stop people asking for access. The project ends. The site stays. Two years later someone saves a spreadsheet of pay bands into a library on that site, because that library is where the team keeps things, and nobody has looked at the site membership since the day it was made.
Search could always return that file. In practice it rarely did. Enterprise search rewards people who already know roughly what they are looking for and can guess at the words in the document. Copilot does not need the words in the document. It reads the contents and answers the question in a sentence, in a tone that sounds like the answer has been checked.
So the access model was never doing all the work. Obscurity was doing a fair share of it. Nobody wrote obscurity down as a control, but it functioned as one, and Copilot removed it in a single licence assignment. Say that out loud in the room. The alternative version, in which the AI leaked something, sends people hunting for a technical culprit that does not exist.
The control in your rollout plan is being retired
If your Copilot governance plan says you will use Restricted SharePoint Search, the plan is out of date. Microsoft is retiring it, new enablement is blocked from 31 July 2026, and customers are directed to Restricted Content Discovery instead (Microsoft’s documentation).
The rename matters less than the reason people reached for it. Restricted SharePoint Search was a stopgap, and it was overwhelmingly used by organisations that had already committed to a go-live date and needed something to stand between Copilot and a tenant they had not tidied. The intention was always that the permissions work would happen behind it. For most of them the permissions work did not happen. The stopgap quietly became the architecture, and it has now been taken away.
If that describes you, the useful response is not to swap one control for another and carry on. It is to notice how long you have been running on a temporary measure.
Restricted Content Discovery does something people do not expect
Restricted Content Discovery is a site-level control and part of SharePoint Advanced Management. Two things it does not do, and both catch people out: it does not change permissions, and it does not remove content from the search index (Microsoft’s documentation).
That first point is the one to take into the security conversation. Applying RCD does not make a site more secure. Anyone who could open that spreadsheet before can still open it. What changes is whether the content can be surfaced by Copilot. If someone in your organisation is treating RCD as remediation for a permissions failure, they have misread it. It is a discovery control wrapped around a permissions problem that is still there.
The third behaviour is the one nobody expects. RCD also strips the AI entry points out of the site — the Copilot button, the AI actions menus including the one for creating agents, and Create pages with AI (same source).
Read that again in terms of what your users will see. This is not a background setting. It is a visible change to the site. Buttons that were there on Thursday are gone on Friday. If you apply RCD across two hundred sites in a maintenance window and tell nobody, you have made a change to a large chunk of the intranet and your service desk will find out from tickets.
The agent creation piece deserves its own thought. Teams that had started building small SharePoint agents scoped to their own library lose the ability to make them on a restricted site. Sometimes that is exactly what you wanted, because the site was never a sensible grounding source. Sometimes it is collateral damage to a department that was doing the right thing. Either way, decide it deliberately rather than discovering it.
One more limit: RCD applies to SharePoint sites, not OneDrive (same source). A good share of the material that worries people is not on a site at all. It is the copy someone saved to their own drive and shared with a link, three job titles ago. No site-level control reaches that.
Check what you already own before you buy it
SharePoint Advanced Management is included with the Microsoft 365 Copilot licence (Microsoft’s licence feature overview).
I have now seen it appear as a separate line item in a business case more than once, next to the Copilot line, in the same document. If you have bought Copilot, look at what is already sitting in the tenant before anyone raises a purchase order. This is the cheapest finding in the whole exercise and it takes about ten minutes.
Every site you restrict is an answer Copilot cannot give
Here is the part that governance workshops skip. Microsoft’s own guidance cautions that excessive use of Restricted Content Discovery degrades Copilot answer quality (Microsoft’s documentation).
That is not a footnote. It is the central trade-off of the whole activity. Copilot’s usefulness comes from grounding in your content. Restriction is subtraction. Apply it broadly, as a default posture, and you have built a Copilot that cannot answer questions about your own organisation. The per-user cost does not go down to match. The business case will not survive renewal.
I have changed my mind about this over the last two years. My early instinct was to restrict widely and open up later, on the reasonable grounds that you cannot un-expose a document. I now think that ordering is wrong for most organisations, because “open up later” never gets scheduled and the product gets judged on the answers it gave while blindfolded. The failure mode of over-restriction is quiet. Nobody raises an incident. Usage just sags, the champions go quiet, and someone in finance asks what you are paying for. That is a worse outcome than it looks, because it is much harder to reverse than a single embarrassing search result.
So restriction should be a scalpel applied to a named list of sites, each with an owner who has agreed to it, and each with a reason written down. It should not be a policy applied to a wildcard.
The work is ownership, and nobody wants it
You cannot make a sensible per-site decision about a site that has no owner. So the first job is not a control at all. It is a list: which sites are broadly accessible, who owns each one, and what is actually in them.
That list is where the real findings are, and they are rarely the ones people expect. The genuinely sensitive material is usually in three or four known places and is often already handled. The problem is the long tail — the sites whose owner left, the ones created for a supplier who stopped being a supplier years ago, the team drives that were migrated in a hurry and inherited permissions from a folder structure nobody has seen since. If the answer to “who owns this” is a leaver, that is not an obstacle to the work. That is the work.
For measurement, use what is already there: the readiness, usage and credits reporting in the Microsoft 365 admin centre, Purview audit logs, and Copilot Analytics (Microsoft’s admin reporting documentation). Microsoft’s own framing for all of this is the Copilot Control System, which splits into security and governance, management controls, and measurement and reporting (overview). That split is a reasonable way to structure a plan. Notice which pillar gets the budget. It is the first one. The third is the one that decides whether you still have the licences next year.
What I would do
In this order, and not a different order.
- Build the list before you touch a setting. Broadly accessible sites, named owner, rough contents. No control is a substitute for knowing what is there.
- Stop any plan that depends on Restricted SharePoint Search. New enablement is blocked from 31 July 2026.
- Check whether SharePoint Advanced Management is already covered by your Copilot licences before anyone quotes you for it.
- Apply Restricted Content Discovery to specific named sites with a written reason, and tell the people who use those sites that the Copilot button and agent creation are going away.
- Fix ownership first, then permissions, then labelling. Every step after ownership is guesswork without it.
- Re-check answer quality after each batch of restrictions, not at the end. The degradation is gradual and you will not spot it in one measurement.
None of this is fast and none of it is interesting to a steering group. It is also the only version of the work that leaves you with a Copilot that is both safe and worth the money. The organisations that got this right did not find a better control. They accepted that the tidy-up was theirs, and started.