Copilot isn't 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 tenant 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 against a neglected estate and you'll surface hundreds, even thousands, of permission issues; content shared with "everyone," links that never expired, sites nobody owns (Microsoft Learn). That is a real problem many organisations face.

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

This post is about the half that goes undiagnosed.

What the silence actually costs

On a Copilot adoption project at a regulated client, 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 and 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 of the silent failure. It doesn't just waste a licence — it teaches your workforce that the governed tool doesn't work, and sends them somewhere worse.

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 estate swells into the dozens, sometimes past a hundred labels. It looks like a mature security posture. It is two different jobs crammed into one control until that control buckles.

Why that blinds Copilot

Copilot doesn't get a god's-eye view of your tenant. It can only reason over content the signed-in user is already allowed to open and where a label applies encryption, that user must hold the EXTRACT and VIEW usage rights before Copilot can touch the content at all (Microsoft Learn). That's documented behaviour, not a misconfiguration.

So every grant you narrowed, you also narrowed what Copilot can read. And if you reached for Double Key Encryption, where you hold one of the two keys, Copilot is shut out completely: DKE-protected content isn't readable by Microsoft 365 services (Microsoft Learn). You built a vault. The AI can't get in. Increasingly, neither can the people who would have benefited from it.

Why one failure gets fixed and the other festers

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 effort into the oversharing side — it's visible, it's auditable, it has a report — and never even diagnose the lockout. Not because the lockout is rarer. Because nobody is looking for it.

The two checks you can run this week

You can measure both directions, and you should.

For over-restriction: open your default sensitivity label and read its usage rights. Does it grant EXTRACT and VIEW to all employees — encrypted, but readable by Copilot — or was it scoped to a narrow group by reflex? Then count how many of your labels bake in a specific access group. That count is your over-restriction surface.

For oversharing, in parallel: run SharePoint Advanced Management's Data Access Governance or Oversharing Baseline report and work the sites it flags (Microsoft Learn).

And clear up the myth that drives the lockout in the first place: Customer Key and bring-your-own-key content is supported and returnable by Copilot — only Double Key Encryption locks it out (Microsoft Learn). "I want to control the key" and "I want Copilot to work" are not in conflict for most of your data.

One design move that fixes both

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 right-sizes both directions on purpose: 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.

This is the layer every AI-governance framework assumes you can already reason about.