Perspective

Copilot did not leak anything

An AI assistant inside your tenant shows people what they already had access to. When that turns out to be more than anyone intended, the finding is not about the AI. It is about a permissions model that was only ever protected by how hard things were to find.

·

9 min

var(--variable-rpcX8dOAk)

Key findings

Microsoft 365 Copilot retrieves content through Microsoft Graph and operates within each user’s existing permissions. It does not show anyone a document they could not already open.

In most tenants, standing access is far broader than anyone believes. That was tolerable while finding content required effort, because obscurity was quietly doing the work of access control.

The second failure is content rather than access. A model retrieving from a library holding five versions of a policy will answer confidently from whichever one it finds.

Both problems existed before the deployment and will outlast it. Switching the assistant off restores the obscurity and leaves the underlying condition in place.

An organization licenses an AI assistant for its tenant. Within a fortnight, somebody asks it a question and gets an answer from a document they were never meant to see.

The reaction is predictable and almost always wrong. The tool is blamed, the rollout is paused, and somebody asks whether the AI can be made to respect permissions.

It already does.

Microsoft’s own readiness guidance is explicit that Copilot and agents retrieve data from Microsoft Graph and respect existing permissions, sharing settings, and policies. If a user cannot open a file directly, the assistant cannot use it either. There is no separate permission model and no bypass.

What changed is not access. It is effort.

Obscurity was doing the work

In a large SharePoint estate, permissions have been drifting for years. A group granted access temporarily in 2022 and never revoked. An “Anyone” link buried in a document library. A site shared with the whole organization for one project that ended. Guests added to a workspace five years ago who still appear in the membership.

None of it was catastrophic, because finding content took work. You had to know the site existed, navigate to it, and search inside it. Most people did not, so most overshared content was never opened by anyone who should not have opened it.

That friction was functioning as a control. Nobody designed it that way and nobody would defend it if asked, but it was load-bearing.

A conversational assistant removes it entirely. A user asks a question in plain language and the system searches everything they are entitled to search. Standing access that was theoretically broad becomes practically broad, instantly, at scale.

The exposure was already there. What arrived was the discovery.

Why “everyone except external users” is the usual culprit

The single most common oversharing vector in Microsoft 365 is the group named “Everyone except external users.” Content shared with it is reachable by every internal account in the tenant.

It gets used because it is the obvious choice when someone wants colleagues to see something and does not want to think about which colleagues. It is one click, it solves the immediate problem, and it is invisible afterwards.

Multiply that across a few years of ordinary work and the result is a tenant where a meaningful fraction of content is available to everyone, and no single person made that decision.

Broken permission inheritance, ownerless sites, and stale guest access compound it. Each one is individually defensible. Together they describe an access model nobody would approve if it were presented as a design.

The half that is not about permissions

Fix every permission and a second problem remains, and it is the one that quietly destroys trust in a deployment.

An assistant grounded in your own content is only as good as that content. In most organizations the same policy exists in four places. The current employee handbook sits next to the two previous versions, none of them marked. A process document describes a system decommissioned eighteen months ago. A project site holds a proposal that was never accepted, written in the same confident voice as the one that was.

A retrieval system has no way to know which is authoritative. It finds relevant text and answers from it.

So a user asks a straightforward question, receives a confident and wrong answer, and concludes that the AI is unreliable. What actually happened is that the AI faithfully reported what your own document library says, and the library disagrees with itself.

This is harder to fix than permissions, because permissions can be audited by a tool and content authority cannot. Somebody has to decide which document is current, and that somebody has to have the standing to say so.

Both problems predate the deployment

The uncomfortable part of this argument is that neither of these is an AI problem, and neither one arrived with the license.

A permissions model nobody has audited is a risk whether or not anything is searching it. A document estate where nothing is authoritative is already producing wrong decisions, made by people reading the wrong version, at a lower rate and with less visibility.

The assistant does not create either condition. It measures them, publicly, in front of the staff who asked the question.

Which is why switching it off is such an appealing response. It restores the friction, the symptom disappears, and the organization returns to not knowing. The finding was real, and it was uncomfortable, and turning off the instrument does not make it untrue.

After a disappointing AI deployment

What gets blamed

What actually happened

The AI exposed confidential information

The AI exposed confidential information

The AI showed someone a file their account could always open

The AI gave a wrong answer

The AI gave a wrong answer

The AI answered from the outdated document nobody deleted

The AI is not secure enough for us

The AI is not secure enough for us

The access model was never audited, and now it has been

Staff do not trust the results

Staff do not trust the results

The content it retrieves from is inconsistent, and they are right not to

We need to restrict what the AI can see

We need to restrict what the AI can see

You need to restrict what the account can see, which was always true

We will revisit AI when the product matures

We will revisit AI when the product matures

The blocking issue is in your tenant, and no product release fixes it

What to do, in order

The work is unglamorous and it is mostly not AI work.

Establish current state before enabling anything. Run the tenant-level reports first. Microsoft’s Data Access Governance reporting exists for this. Start the site permissions snapshot report well before you plan to deploy rather than during it, and note that organizations without SharePoint Advanced Management have to switch on data collection before the activity reports work at all, with reports appearing 24 hours later and holding only the last 28 days.

Deal with the broad groups first. “Everyone except external users” on sites holding anything sensitive. Organization-wide sharing links. Sites with no owner, which means no one to ask whether the access is still appropriate.

Then guests and inheritance. Stale external accounts, and libraries where permission inheritance was broken for a reason nobody remembers.

Understand what the restriction controls actually do, because they are not interchangeable. Restricted Content Discovery hides a site from the assistant and from organization-wide search while leaving site permissions unchanged. Restricted Access Control changes who can open the site at all, by granting access through a named group. Restricted SharePoint Search was the third option and is being retired: Microsoft blocked new enablement on 31 July 2026, and it was never more than a 100 site allow list intended as a holding measure. Choosing the wrong one produces either a false sense of security or an outage for a team that legitimately needed access.

Separately, decide what is authoritative. For each significant content area, one current version, marked as such, with the superseded ones archived or deleted. This is the step most often skipped, because it requires decisions rather than configuration.

Then deploy, to a pilot group, and read what they ask. The questions people actually put to an assistant are the fastest map of where your content and access model are weakest.

The part vendors do not sell

One practical note worth knowing, because it changes the economics. SharePoint Advanced Management carries the oversharing reporting and the access review tooling, and it is included with Microsoft 365 Copilot. Microsoft’s documentation states that if your organization assigns at least one Copilot license to a user, SharePoint administrators get the SAM features that support your Copilot deployment. Data Access Governance reporting, Restricted Access Control, Restricted Content Discovery, the “Everyone except external users” insights and site access review are all in that set. One feature, restricted site creation by apps, still needs the separate SAM Plan 1 add on.

So the tooling to do this work is already paid for by the license that created the need for it.

The larger point is that the preparation is bigger than the deployment, and nobody sells it because it is not a product. A license is a transaction. An access review is a project with no launch event, no demonstrable new capability, and a finding at the end that says your permissions were wrong.

That project is the actual work. The assistant is the easy part, and the reason organizations are disappointed by it is that they bought the easy part first.

What this is

This is a position rather than a finding. The technical claims about how Copilot handles permissions, what the restriction controls do, and how SharePoint Advanced Management is licensed are Microsoft’s documented behavior and are cited below. The argument built on them, that most AI disappointment is displaced from its real cause, is ours.

Sources

  1. Microsoft. Get ready for Microsoft Copilot with SharePoint Advanced Management. Microsoft Learn, updated 18 August 2026. “Copilot and agents retrieve data from Microsoft Graph and respect existing permissions, sharing settings, and policies.”

  2. Microsoft. SharePoint Advanced Management features in Microsoft Copilot licenses. Microsoft Learn, updated 18 August 2026. Lists the SAM features included with a Copilot license, and the one that is not.

  3. Microsoft. Data access governance reports for SharePoint sites. Microsoft Learn, updated 30 July 2026. Snapshot and activity reports, and the data collection requirement for organizations without SAM.

  4. Microsoft. Restrict discovery of SharePoint sites and content. Microsoft Learn. Restricted Content Discovery limits discoverability without changing permissions.

  5. Microsoft. Restricted access control for SharePoint sites. Microsoft Learn. Access is granted through a named group, and users outside it lose access even if they had it before.

  6. Microsoft. Restricted SharePoint Search. Microsoft Learn, updated 18 August 2026. “Restricted SharePoint Search is retiring. Starting July 31, 2026, new enablement is blocked.” Allow list limited to 100 sites.

  7. Qwalora, “Microsoft’s nonprofit licensing change was a security change.” Research, September 2026.

Tell us what you are deciding.