Restricted Content Discovery Hides Files. It Doesn’t Stop Your Agents.

If you are rolling out Microsoft 365 Copilot, you have probably heard this advice: “Set Restricted Content Discovery on the sites with messy permissions and fix them later.” I recently read a test by Julian Kusenberg and Tomislav Karafilov that shows why that plan needs a second look.

The test setup

They enabled RCD on a SharePoint site with two Word documents and searched for a distinctive keyword. The account used had full access to the files.

• SharePoint search (org-wide and from another site) found nothing.
• Microsoft 365 Copilot Chat and Copilot Search found nothing.
• Searching from within the site itself found the file. Microsoft documents this behavior.

So far, RCD did exactly what Microsoft promises.

Where the agent took another route

Then they asked a Copilot Studio agent on the GitHub Copilot harness what it could find about the keyword. The site was configured as its knowledge source.

1. The agent ran a lexical search and got zero results.
2. It ran a semantic search and got zero results again.
3. It retried with variations and found nothing.
4. It switched to the tool Filter SharePoint Files by Metadata and listed the site’s files by modification date.
5. The restricted file appeared. The agent analyzed it and returned a summary with citations.

Nobody told the agent to do this. It simply tried the next tool in its belt.

Is this a vulnerability?

Not in the classic sense. The authors saw no permission bypass, because the user could have opened the file anyway. RCD is a discoverability control, not an authorization boundary. Microsoft says so in its documentation.

The risk is the gap between expectation and reality. Imagine an HR or finance site that is shared with all internal users. You set RCD to keep it out of Copilot until the cleanup is done. An agent working on behalf of any of those users might still surface the content. The authors did not test this with a broad group, so treat it as a hypothesis to verify in your own tenant.

What you can do about it

1. Fix permissions, don’t just hide them. Use Data Access Governance reports to find broad grants like “Everyone except external users.”
2. Use Restricted Access Control for sites that must stay dark. It limits who can access the site at all.
3. Use sensitivity labels with encryption for document-level protection. Then test your agents against labeled files.
4. Govern agent tools, not just agents. “SharePoint as knowledge” is not one capability. In this test it meant at least three different tools.
5. Test with several identities. Run the same prompt as maker, as regular member and as a user without access, in the test pane and in the published channel.
6. Check what Purview Audit records for agent runs. Do this before you need it in an investigation.
7. Communicate RCD for what it is. It is a temporary visibility filter, not an access restriction.

My takeaway

An agent is not a search query. It is a planner with tools, and every retrieval tool is its own discovery path. RCD takes a site out of the directory, but it doesn’t lock the doors.

A few questions remain open: whether this is intended design or a gap, how published agents behave, and how the file content was fetched. It was one tenant and two documents. Still, the lesson for any Copilot readiness plan is clear. Clean up the permissions first, and test your agents the way they will actually behave.

Source: Julian Kusenberg, “Restricted Content Discovery Hid the File. The Agent Took Another Route” (kusenberg.net, November 2026). Thanks to Julian and Tomislav for sharing this.