Microsoft 365 Copilot for SharePoint ships an AI assistant directly into SharePoint sites in the form of "agents." Organizations with the right Copilot licensing get a Default Agent automatically, scoped to each site, with no setup required. You can ask it questions in plain language and it will read across the documents in that site to answer. That is the entire pitch: stop hunting through folders, just ask.

In May 2025, red teamers at the UK security consultancy Pen Test Partners published two writeups showing what happens when you point that convenience at files you are not supposed to be able to read. The short version: Copilot read them out anyway, and it did so without leaving the usual fingerprints.

What Restricted View is supposed to do

SharePoint has a permission level called "Restricted View." The point of it is to let someone read a file in the browser while blocking the things that let them walk away with a copy. With Restricted View, a user is not meant to be able to download the file, copy its contents, print it, or open it in a desktop application like Excel or Word. You can look, but you cannot take. It is the digital equivalent of a document you can read through glass.

Plenty of organizations lean on this. It is the control you reach for when a file has to be visible to a broad group but must not leave the building - contracts, internal reports, and, inevitably, the kinds of files that should never exist but always do: spreadsheets full of passwords, key material, and exported customer data.

How Copilot walked straight through it

The Pen Test Partners team came at a large SharePoint instance the way an attacker with a foothold would: too much content to sift through by hand, so they asked Copilot to do the heavy lifting. With some careful prompting, the agent happily surfaced interesting material, including a file the testers described as holding credentials.

Then they hit the wall. SharePoint, doing its job, blocked the direct attempt to open and download the protected file under Restricted View. So the testers simply asked Copilot to read it instead. The agent, acting on behalf of the same user account, retrieved the file and printed its contents into the chat - including, in their example, the passwords that unlocked an encrypted spreadsheet.

The bypass hinges on a gap that is almost funny once you see it. Restricted View blocks copying the file. It says nothing about copying the chat. As Pen Test Partners put it, the team was "not meant to be able to open Restricted View files to download them or their content," but they "are able to copy the content of Copilot chats." So you do not attack the file at all. You ask the assistant to read it aloud into a text box you are fully allowed to highlight, copy, and paste somewhere else. The protected content launders itself through the AI's output window.

In their follow-up post specifically about Restricted View, the team demonstrated this was not a one-off Copilot quirk. They showed several independent ways to defeat the control - optical character recognition on the rendered text, the browser's Immersive Reader, and ordinary developer tools - alongside the Copilot route. Copilot was just the easiest and the most polished, because it does the reading and reformatting for you.

The part that should worry the blue team

Defeating an access control is bad. Defeating it quietly is worse.

When a user opens a file in SharePoint the normal way, it leaves a trace. The file shows up in "accessed by" style lists and recent-activity views that defenders and auditors can review. That breadcrumb is part of how you reconstruct what an intruder touched after an incident.

Pen Test Partners reported that their Copilot-driven reconnaissance did not show up in those standard "accessed by" lists. An analysis from the Office 365 for IT Pros team, writing about the same research, made the same point bluntly: unlike trawling through SharePoint files directly, Copilot access "doesn't leave breadcrumbs like entries in the last files accessed list." So an attacker with a foothold could use the AI to enumerate and read sensitive content while generating far less of the telemetry that would normally light up a security dashboard.

Put those two facts together and you get a tidy recon tool: ask a question, get the contents of restricted files back as copyable text, and skip much of the audit trail. The AI assistant becomes the mechanism that both defeats the permission and dampens the alarm.

What this is and is not

It is worth being precise, because this incident is easy to over-claim.

This is not a remote code execution bug, and it is not a prompt-injection attack where hidden instructions in a document hijack the model. The user is asking Copilot to do something on purpose. The failure is one of authorization: the assistant is willing to surface content that the access model said this user should not be able to take, and it does so through a channel - chat text - that the access model never thought to lock down.

It also requires a prerequisite that matters. To use Copilot for Microsoft 365, an attacker has to be able to sign in as a licensed user. As the Office 365 for IT Pros write-up stressed, "before an attacker can use Copilot for Microsoft 365, they must be able to sign into a licensed user's account." This is a privilege-and-exposure problem, not a way for an anonymous stranger on the internet to read your SharePoint. The realistic threat models are an insider, a compromised account, or an over-permissioned employee who can now strip-mine restricted content with a chatbot.

And, importantly, there is no named victim and no confirmed breach attached to this disclosure. This is documented red-team research demonstrating a hazard, not a reported theft. Microsoft's position, as relayed in the coverage, is that Copilot only returns content the signed-in user already has permissions to, and that the answer is correct configuration - sensitivity labels, data loss prevention policies for Copilot, and Restricted Content Discovery. That is technically accurate. The problem is that it sidesteps the gap between what the access model intended (you may look, you may not take) and what actually happened (you took, via the assistant, and the log barely noticed).

Why it matters

Restricted View encodes an assumption: that there is a meaningful difference between letting a human read something on screen and letting them copy it. That assumption was already shaky in a world with screenshots and OCR. Drop a tireless assistant into the same site - one whose entire job is to read documents and re-emit their contents as clean, copyable text - and the assumption stops holding at all.

The lesson is not "turn off Copilot." It is that a control designed for the threat model "a person clicking around the UI" does not automatically survive contact with an AI agent that reads everything in scope and reformats it on request. If your data security plan depends on Restricted View as a hard boundary, an AI assistant with the same permissions as the user is a way around it. As Pen Test Partners concluded, Restricted View "can not be relied on to secure data against motivated attackers." Sensitive files - especially the spreadsheet of passwords that should not exist - need an access decision, not a viewing restriction layered on top of broad access. [1]

The other lesson is about visibility. An AI assistant that can read protected content while generating less audit telemetry than a manual file open is a gift to anyone who has already gotten inside. Detection and logging built for human browsing behavior may simply not see the assistant doing the same reconnaissance faster and quieter.

[1] The recurring theme of agentic SharePoint disclosures is that the AI keeps inheriting the user's full reach and then making it trivially easy to exercise. The convenience and the hazard are the same feature viewed from two sides of the access boundary.