Copilot Doesn’t Know About Your Unwritten Rules

There’s a governance practice that lives entirely off the books in most organizations. IT never documented it, Security never approved it, but everyone quietly relies on it.

It goes something like this: sensitive content lives in a SharePoint site with a cryptic name, minimal links pointing to it, and no formal access controls beyond “only the people who know it exists actually go there.” The assumption is that obscurity equals protection. If nobody looks, nothing leaks.

Microsoft 365 Copilot has made that assumption spectacularly wrong.

The Accidental Exposure Problem

Copilot doesn’t navigate SharePoint the way a human does. Humans browse,  follow links, read site names, and apply social context about what they probably shouldn’t be clicking on. Copilot does none of that. It surfaces content based on permissions. If a user has view rights to a file — for any reason, including inherited permissions from an overly broad group membership — Copilot can reference that file in a response.

Microsoft is explicit about this in its own documentation (https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy): Copilot only surfaces organizational data to which individual users have at least view permissions. That sounds reassuring until you map it to the actual state of your tenant. Most organizations have years of permission drift: inherited access from group memberships that were never cleaned up, SharePoint sites shared with “Everyone except external users” because someone needed quick access in 2019, libraries with broken inheritance that nobody has audited since the original site owner left the company.

None of that was a visible problem before. Users weren’t going to stumble into a poorly named SharePoint library on their own. Copilot makes it even easier for SharePoint data to fall into the wrong hands if permissions are not properly configured. The AI doesn’t share your institutional knowledge about which folders are politically sensitive, which documents are drafts that were never meant for broad consumption, or which sites contain HR data that somehow ended up accessible to the entire sales department.

The unwritten rules don’t travel. The permissions do.

What “By Design” Actually Means

Here’s the part that often gets lost in the security conversation around Copilot: the system is working exactly as intended. Copilot operates within the principle of least privilege, meaning it only surfaces content the user already has rights to view. It does not bypass Microsoft 365 access controls or expose data across tenants. However, any existing permission sprawl or misconfigured sharing settings directly impact what Copilot can reach.

I refer to this as “The Delve Effect.” When Microsoft Delve was launched a few years back, people were up in arms about “broken permissions.” But their permissions were not broken — they were working as designed. Security through obscurity is no more.

So here we are today. This is not a Copilot bug, but a permissions hygiene problem that Copilot has made impossible to ignore.

The good news — and there is genuine good news here — is that the Microsoft stack gives you the tools to fix this properly. Microsoft Purview Data Loss Prevention for Copilot is now generally available, blocking Copilot from processing files and email with specific sensitivity labels (https://learn.microsoft.com/en-us/purview/dlp-microsoft365-copilot-location-learn-about). More recently, DLP protection has extended to prompts themselves, scanning user text input in real time for sensitive information types, whether built-in or custom-defined by your organization, and restricting the prompt from being processed if a match is detected.

Sensitivity labels and DLP are not afterthoughts bolted onto Copilot. As Microsoft’s own sensitivity label documentation makes clear (https://learn.microsoft.com/en-us/purview/sensitivity-labels), Copilot and agents recognize and integrate sensitivity labels into user interactions to help keep labeled data protected. That integration is architectural. It was designed in. Which means the governance framework you build around sensitivity labels pays dividends not just for today’s Copilot deployment, but for every agent and AI-powered capability that follows.

This is exactly why the InsideTrack governance guidance from Microsoft is explicit on one point: Copilot respects sensitivity labels and DLP policies by design. The operative word is “respects.” If you have not applied sensitivity labels to your content — and most organizations have not applied them consistently — Copilot has nothing to respect.

The Audit You’ve Been Avoiding

Microsoft Purview and SharePoint Advanced Management (SAM) can find sites and files that are overshared, ownerless, inactive, or contain sensitive data that could be surfaced by Copilot (https://learn.microsoft.com/en-us/microsoft-365/copilot/configure-secure-governed-data-foundation-microsoft-365-copilot). The SAM Content Assessment identifies sites with oversized audiences, broken inheritance, inappropriate sharing, and those that are inactive or ownerless.

Run that report before you roll out Copilot broadly. Not after. The organizations that have done this consistently report the same thing: the results are uncomfortable. Not because the data reveals something catastrophic, but because they confirm what most IT pros quietly suspected — the permission state of the average Microsoft 365 tenant is far messier than anyone officially acknowledged.

That messiness was survivable in a world where content discovery required deliberate navigation. It is not survivable in a world where an AI assistant can synthesize across your entire accessible data estate in seconds.

The Practical Starting Point

You do not have to solve the entire permissions debt before enabling Copilot. That would take longer than anyone has. But you do need a plan that prioritizes the highest-risk content first.

Start with sites containing HR, legal, finance, or executive content and verify that access is scoped correctly. Apply sensitivity labels to that content — even a simple, well-structured label schema gives Copilot and Purview DLP something to enforce. (You know, this probably needs its own article.) Use SharePoint Advanced Management to identify sites with broken inheritance or broad sharing links that warrant immediate remediation, and establish a rhythm for ongoing review. Permission hygiene is not a project with a completion date.

The unwritten rules that protected sensitive content for the last decade are gone. The written ones — enforced through labels, DLP policies, and properly scoped permissions — are what you have now. That is actually a more defensible position. It just requires you to write the rules down.