Copilot Didn’t Overshare Your Data. Your Permissions Did

That’s Microsoft 365 Copilot, and it’s working exactly as designed and exposing IT’s dirty little secret: We haven’t spent enough time managing data.

The practical answer is not to delay Microsoft 365 Copilot rollout forever or pretend permissions can be fixed manually across a mature tenant. IT should first restrict Copilot discovery from the obvious high-risk areas, then use Purview and SharePoint Advanced Management to identify the less obvious oversharing patterns. The mistake is treating this as an AI governance project. It is really a permissions, ownership, and data lifecycle project that Copilot finally made impossible to ignore.

Copilot surfaces documents, emails, Teams chats, and SharePoint content based on a user’s existing permissions. Microsoft is explicit about this. Copilot does not bypass security; it reflects it. The problem where Copilot is surfacing confidential data isn’t a bug; it’s a data management failure and we are all guilty of it.

Permission sprawl that accumulated over years is now discoverable in seconds through plain-language prompts. A finance analyst who technically had access to a payroll bonus spreadsheet but never looked for it now gets that data surfaced when she asks Copilot to summarize compensation trends.  

When Copilot hit the market, nobody wanted to pump the brakes until their data could be restructured. We knew about it. You may have mentioned it to your boss, or the client, but nobody scheduled time to fix it before the rollout. Probably because it’s an expensive fix and it’s one of those “things” that they thought IT was already handling. They have a point. Data management is basic security.

Permission sprawl is bigger than most Microsoft 365 tenants admit

Concentric AI’s 2025 data risk research found that 16% of business-critical data in the average Microsoft 365 tenant is overshared. 16% sounds like something that we could easily get our hands around and fix. The problem is identifying where those files are.

Microsoft 365 Copilot turns hidden access into instant discovery

The common culprits are well-known to any tenant admin who has done a permissions audit: the Everyone except external users (EEEU) group applied to SharePoint sites that were never intended to be company-wide; broken permission inheritance where a folder within a restricted library somehow has a broader audience than the library itself; and anonymous sharing links that never expired because nobody created an auto-expire policy.

It’s also job changes resulting in new permissions being granted. That person still needs access to the data from their previous position in the company, “for a while”, the next ticket comes into the helpdesk, and IT loses the plot. Individually, none of these felt catastrophic when access required a deliberate search. Collectively, they represent a surface area that Copilot queries in milliseconds.

EchoLeak showed why bad permissions become AI risk

Security researchers disclosed CVE-2025-32711 (dubbed EchoLeak) a zero-click prompt injection vulnerability in Microsoft 365 Copilot. An attacker could embed a malicious payload in an ordinary email or document. When the recipient invoked Copilot to summarize it, with no other action required, Copilot could silently exfiltrate sensitive data from the user’s context to an attacker-controlled URL. No macro. No link to click. Just an AI assistant doing what it was asked to do with content it trusted.

This flaw has now been patched but the existence of this flaw should have sent up the warning flags that data management needs to become job one.

How IT should contain Microsoft 365 Copilot oversharing risk

The good news is that Microsoft included the tools to address this in your tenant already. Every tenant with even a single Microsoft 365 Copilot license now has SharePoint Advanced Management (SAM) included at no extra cost. SAM includes a Content Management Assessment that flags oversharing, EEEU usage, broken inheritance, and ownerless sites.

Restricted Content Discovery lets admins exclude high-risk SharePoint sites from Copilot indexing entirely while remediation is underway. Users retain access, Copilot does not. Microsoft Purview’s Data Security Posture Management (DSPM) for AI runs ongoing data risk assessments and can configure Data Loss Prevention (DLP) policies that prevent Copilot from grounding responses in content classified as sensitive.

The tools exist. Guidance exists. But does the will to use them exist?

Here’s how I’d proceed:

1. Restrict Copilot from sensitive areas that you know about. Temporarily restrict Copilot discovery for the sites you already know are sensitive: HR, finance, legal, executive planning, M&A, and customer escalation workspaces.
2. Implement Purview DSPM for AI because it’s easy to set up.
3. Fix site ownership and broad access before chasing edge cases. Use SharePoint SAM to fix EEEU permissions, anonymous links, ownerless sites, and broken inheritance because these items will usually create more real exposure.
4. Follow-up on what these tools have uncovered. Make remediation recurring. Copilot readiness is not a one-time cleanup because sharing drift resumes the moment users create new teams, sites, folders, and links.

The real Copilot readiness test is data ownership

Copilot didn’t create the oversharing problem. It just gave it a prompt interface. The judgment call for IT leaders now is deciding how much of that backlog to clear before the next Copilot capability ships because the next one will certainly carry a new surprise. Just witness the ability to onboard LLMs that live outside of the protected tenant boundary and don’t have to adhere to the privacy rules. That’s another whole problem for a different day.

If your tenant still depends on obscurity, like old sites nobody visits, folders nobody audits, sharing links nobody owns, then Copilot removes that safety net. The practical default is simple: assume anything broadly accessible is now broadly discoverable, and govern it accordingly.