Copilot is not broken. It's locked out.

Everyone prepping for Copilot hears the same advice: fix your oversharing first. It's good advice, but in a regulated industry it's only half the job. The other half nobody warns you about: you can lock content down so hard that Copilot goes blind to data your users have access to. And unlike oversharing, that failure never trips an alarm.

Both failures can coexist

This is not an argument to skip oversharing cleanup. You still have to do it. Run SharePoint Advanced Management's Data Access Governance reports across a SharePoint environment nobody's cleaned up in years and you'll surface hundreds, even thousands, of permission issues: content shared with "everyone," links that never expired, sites nobody owns. That is a real problem many organisations face.

But in a cautious, regulated organisation a second failure runs right alongside it, and it's the one almost nobody looks for. Everything confidential gets wrapped in the heaviest encryption available "to be safe," and Copilot can't read any of it. So you can do both at the same time: overshare and over-restrict.

This post is about the half that goes undiagnosed.

What the silence costs, and why it stays silent

On a Copilot adoption project at an organisation in a regulated industry, we surveyed users on why uptake was so poor. The answer was almost unanimous: they had come for the promise of finding current, relevant information fast. They left disappointed when Copilot returned incomplete drafts, stale data, or nothing at all for content they knew they had access to.

Having decided Copilot was broken, they did one of two things. Some drifted to ungoverned AI tools in the browser, the exact shadow-AI problem the lockdown was meant to prevent. Others stopped using AI for work entirely, trust gone.

That's the real cost: it doesn't just waste a licence — it teaches people the approved tool doesn't work and pushes them somewhere worse.

Oversharing fails loud: someone sees a document they shouldn't, files a ticket, and a permission gets tightened. Over-restriction fails silent. "The AI didn't find anything useful" never gets escalated as an incident. So teams pour their effort into the oversharing side, because it's visible and auditable and has a report, and they never even diagnose the lockout. Not because the lockout is rarer. Because nobody is looking for it.

How over-restriction happens

Over-restriction happens when classification turns into access control.

A sensitivity label is meant to answer one question: what is this information? Somewhere it starts answering a second: who is allowed to see it? Each new team gets its own label with an access group baked in. Each project brings an exception. Routine documents get encrypted by reflex. The label count swells into the dozens, sometimes past a hundred. It might look like a mature security posture. But it is two different jobs crammed into one control until that control breaks.

Why that blinds Copilot

Copilot doesn't get a god's-eye view of everything in your Microsoft 365 environment. It can only reason over content the signed-in user is already allowed to open. And where a label applies encryption, that user needs two specific usage rights first: EXTRACT (copy content out) and VIEW (read it). Without both, Copilot can't touch the file. That's documented behaviour, not a misconfiguration.

So every grant you narrowed, you also narrowed what Copilot can read.

And if you reach for the strongest lock, Double Key Encryption, where you hold one of the two keys yourself and Microsoft never gets a copy, you've built a vault. The AI can't get in. Increasingly, neither can the people who would have benefited from it.

The dashboard is blind to it, too

So why didn't you know this was happening?

Because the dashboard you'd expect to catch it can't.

Go to Purview and open your Data Security Posture Management dashboard — DSPM, Microsoft's view of where sensitive data meets your AI. If your environment looks like most regulated ones, the oversharing flags are clear, the risky-prompt count is low, nothing's leaking. By its own scoreboard, your AI is healthy. And Copilot still can't find anything useful.

Look at what DSPM actually does. Its main surfaces — an inventory of your AI apps and agents, an activity view of what they touched, and risk assessments of your busiest sites — all point the same direction. They hunt for data overshared with AI. And every fix-it button it offers, restrict access by label, lock down a site, auto-delete stale files, removes reach. The whole instrument is built for one failure: the AI touching more than it should. Over-restriction is the opposite failure, so it never shows up.

But you can still read DSPM for over-restriction; you just read it against the grain. Look for the AI apps and agents that exist but barely do anything. Look at the prompts that came back with nothing useful, not only the ones that returned something sensitive. The signs are there.

Encrypted is not the same as locked out

So is the answer to strip the encryption off? No. Far from it. Encryption was never the lever. The grant is.

Microsoft's own Secure by Default model proves it. Its default label for documents, Confidential\All Employees, encrypts the file and grants every employee Full Control over it. The content is locked down, and Copilot reads it without a hitch, because every signed-in user already holds the rights it needs. Encrypted is not the opposite of usable.

So from a single label you can get three completely different answers for the AI, and only the grant changes between them. Grant the rights to all employees, and Copilot reads the content freely. Scope the grant to a handful of named people, and Copilot reads it only for them. Apply Double Key Encryption, and Copilot can never touch it.

Which means designing your labels is designing what your AI can read.

One design move that fixes both failures

Stop making one label do two jobs.

Let workspace membership — the Team, the SharePoint site, the container — decide who gets in. Let the label say what the content is, and apply protection proportionate to that, not to which department happened to create the file. The same discipline fixes both issues: it opens routine content Copilot should read, and tightens what's actually overshared — instead of defaulting to lockdown and calling it safety. Most content sits at a labelled default Copilot can use; sensitive material stays encrypted with the right grant; DKE is reserved for the sliver that truly needs you to hold the key.

The checks you can run this week

Confirm sensitivity labels are switched on for Office Online:

Note that sensitivity labels aren't switched on for SharePoint and OneDrive by default. It's opt-in. Until you turn it on, the only encrypted files Copilot and your agents can reach are the ones actually open in an Office app on a Windows PC — what Microsoft calls "data in use." So a label you set up with people in mind can wall your AI out without anyone noticing.

To check: in the Microsoft Purview portal, go to Solutions > Information Protection > Sensitivity labels. If a banner is still offering to turn on processing of Office Online content, it's off. To turn it on, click Turn on now as a global admin — it takes about 15 minutes — or run it from the SharePoint Online Management Shell:

Set-SPOTenant -EnableAIPIntegration $true

Check your over-restriction:

In the Microsoft Purview portal, go to Solutions > Information Protection > Sensitivity labels. Open your most-used label and look at its encryption settings:

• See who's listed under the permissions, and what level they hold. If everyone in your organisation has Co-Owner, Co-Author or Editor, the content is encrypted but Copilot can still read it. If they only have Viewer, Copilot is blocked: Viewer grants read access but not the EXTRACT (copy) right Copilot needs.
• If the label uses Double Key Encryption, or the "let users assign permissions" option, Copilot is shut out outright.
• If the permissions are scoped to one narrow group, only that group's Copilot use works.

Then do the same across your other encrypted labels and count the ones that block Copilot. That count is the size of your over-restriction problem.

Read DSPM against the grain:

Open it for the half it does for free, then go looking for the half it can't: the agents that exist but barely act, the sites your AI never reaches into.

Check your oversharing, in parallel:

This one needs a SharePoint Advanced Management licence (part of SharePoint Premium). In the SharePoint admin center, expand Reports and select Data access governance, then pick a report — start with site permissions for a snapshot of where access is widest, then sharing links and "Everyone except external users" for recent activity — and select View reports. Work down from the most-exposed sites, and hand a flagged site straight to its owner with a site access review.

The bottom line. Copilot isn't broken. It reads exactly as far as your labels let it, and not one document further. The fix isn't to loosen everything or lock it down harder. It's to stop asking one label to carry two jobs, what the content is and who may reach it, in the same breath. Get that right and the silence lifts on its own: the AI starts answering, and the people who'd written it off come back. The lock was never the problem. Where you put it was.