
Is Your Data Safe with Microsoft Copilot? SharePoint Permissions Risks Explained
- Roland Smith
- 6 days ago
- 7 min read
Microsoft Copilot for Microsoft 365 is a genuinely useful tool. But it has one property that turns a common, low-grade problem into an urgent one: Copilot surfaces every piece of data a user has permission to access. Every document. Every email. Every file sitting in a SharePoint library that someone shared too broadly three years ago and forgot about.
Before Copilot, overshared data was a latent risk. A user technically had access to the HR site, but they'd never gone looking for it. With Copilot, they don't need to go looking. They ask a question, and Copilot goes looking for them — across everything they can reach.
This article explains how Copilot accesses data, the most common permission problems we see in real environments, and what you need to fix before turning Copilot on.
How Copilot Accesses Your Data
Copilot uses Microsoft Graph to access data across your M365 tenant. Microsoft Graph is the API layer that connects all M365 services — SharePoint, OneDrive, Exchange, Teams, Planner, and more.
When a user asks Copilot a question, here's what happens:
Copilot receives the prompt and determines what data might be relevant
It queries Microsoft Graph on behalf of the user, using that user's identity and permissions
Microsoft Graph returns results that the user has permission to access — the same results they'd get if they ran the search themselves
Copilot processes those results and generates a response
The critical point: Copilot doesn't bypass permissions. It respects the same access controls that apply everywhere else in M365. If a user can access a document through SharePoint, Copilot can surface that document. If they can't, Copilot can't.
That sounds like a security feature — and it is. The problem is that most organisations' permissions are far more permissive than anyone realises.
The Permissions Problems You Probably Have
After years of working with Australian businesses on their Microsoft 365 environments, here are the permission issues we find in almost every tenant. These aren't theoretical risks — they're things we see in real audits, repeatedly.
1. "Everyone Except External Users"
This is the big one. SharePoint has a built-in group called "Everyone except external users" that includes every person in your organisation with an M365 account. When this group gets added to a SharePoint site's members or visitors, the entire company can access everything in that site.
How does it happen? Usually someone is setting up a new site, gets asked to share it, and adds "Everyone except external users" because it's the quickest option. Or it was set up that way by default and nobody changed it. Either way, that HR site with salary data, that finance site with cashflow forecasts, that executive site with board papers — if this group is in the membership, everyone can see it.
Before Copilot, the risk was theoretical. After Copilot, a user asks "what are the salary ranges for senior engineers?" and Copilot pulls up the answer from the HR site. That's not a bug. That's Copilot working exactly as designed — with permissions that were set up badly.
2. Inherited Permissions
SharePoint uses permission inheritance by default. A subsite inherits permissions from its parent site. A document library inherits from the site. A folder inherits from the library. This is convenient for administration but problematic when sensitive content lives inside a broadly-shared structure.
Example: A department site is shared with the whole department (reasonable). Inside that site, someone creates a folder called "Performance Reviews" and puts individual review documents in it. The folder inherits the department site's permissions — so everyone in the department can access every performance review. Nobody broke inheritance because nobody thought about it.
3. Sharing Links That Never Expire
Every time someone clicks "Share" on a document and creates an "Anyone in your organisation" link, they're creating a permission that persists until someone explicitly removes it. Over months and years, these links accumulate. Files that were shared for a specific purpose remain accessible long after that purpose is done.
Copilot can discover and surface these files when their content matches a user's query. The user who created the link years ago has long forgotten about it, but the permission is still active.
4. Stale Group Memberships
Microsoft 365 Groups (which underpin Teams, SharePoint sites, and Planner boards) accumulate members over time. People get added to project groups, the project ends, and nobody removes them. Staff change roles but keep their old group memberships alongside the new ones.
The result: people have access to far more content than their current role requires. HR staff who moved to marketing still have access to the HR Teams site. Former project members can still see the project's SharePoint content.
5. OneDrive Oversharing
OneDrive for Business is often treated as a personal drive, but it's still part of the M365 ecosystem. When users share entire folders (or their entire OneDrive) with colleagues, those permissions persist. We've seen cases where a user shared their root OneDrive folder with a team — meaning the entire team could access every personal document, draft, and file the user stored there.
6. Teams Channel Files
Every Teams channel has a corresponding folder in the team's SharePoint site. Files shared in a Teams chat or channel are stored in SharePoint and accessible to everyone in that team. Sensitive documents dropped into a Teams channel are often forgotten about but remain accessible indefinitely.
How to Audit Permissions Before Deploying Copilot
You need to understand your current state before you can fix it. Here's a practical approach:
Step 1: Identify High-Risk Sites
Start with the SharePoint sites that contain your most sensitive content:
HR / People & Culture
Finance and accounting
Executive and board
Legal
Client-specific project sites with confidential information
IT / infrastructure documentation (passwords, network diagrams, configs)
Step 2: Review Site Memberships
For each high-risk site, check:
Who are the site owners, members, and visitors?
Are there any broad groups ("Everyone except external users", "All Company", department distribution lists) in the membership?
Are the members still appropriate for the content in the site?
Step 3: Check Sharing Reports
Use the SharePoint admin centre to run sharing reports. Look for:
Files and folders shared with "Anyone" or "People in your organisation"
Sites with a high number of unique permissions (a sign of ad-hoc sharing)
External sharing that's still active
Step 4: Use Purview Data Access Governance
If you're on M365 E5 or have SharePoint Advanced Management, Microsoft Purview provides Data Access Governance reports that specifically identify overshared content and sites. These reports are designed for exactly this scenario — understanding your data exposure before enabling AI features.
Step 5: Run Test Queries
Before you broadly deploy Copilot, give it to a small test group and actively try to surface sensitive data. Ask Copilot questions like:
"Show me salary information"
"Find documents about [confidential project]"
"What are our financial results?"
"Show me HR policies about termination"
If Copilot returns results that the test user shouldn't have access to, you've found a permission problem to fix before wider rollout.
Fixing the Problems
Remove Broad Access Groups
Go through your sensitive sites and remove "Everyone except external users" and similar broad groups. Replace them with specific M365 Groups or security groups that contain only the people who need access.
Break Permission Inheritance Where Needed
For sensitive content within broader sites, break inheritance and apply specific permissions. This is a balancing act — too much broken inheritance makes administration painful, but sensitive content needs appropriate protection.
Clean Up Sharing Links
Review and remove "Anyone in your organisation" sharing links, especially on sensitive content. Set expiry dates on future sharing links so they don't persist indefinitely. In the SharePoint admin centre, you can set default sharing link types and expiry periods.
Review and Prune Group Memberships
Audit M365 Group memberships against current roles. Remove people who no longer need access. Set up regular access reviews — quarterly is a good cadence for most organisations. Entra ID access reviews can automate this process.
Tighten Sharing Defaults
In the SharePoint admin centre, review your organisation-level sharing settings:
Set the default sharing link to "Specific people" rather than "Anyone in your organisation"
Require sign-in for "Anyone" links
Set link expiry defaults (30 or 60 days is reasonable)
Restrict who can share externally
Sensitivity Labels and Microsoft Purview
Beyond fixing permissions, sensitivity labels add a layer of classification and protection to your documents.
What Sensitivity Labels Do
Classify content — mark documents as General, Confidential, Highly Confidential, etc.
Apply protection — optionally encrypt documents and restrict actions (prevent copying, printing, forwarding)
Visual markings — add headers, footers, or watermarks to labelled documents
Control Copilot behaviour — Copilot respects label-based protections. If a document is encrypted with a sensitivity label, only users authorised by that label's policy can access it through Copilot.
Auto-Labelling
Microsoft Purview can automatically detect and label sensitive content based on patterns — Australian Tax File Numbers, bank account numbers, Medicare numbers, and other sensitive information types. This helps catch sensitive documents that don't have labels applied yet.
Sensitivity labels require M365 E3 or above (E5 for auto-labelling). If you're on Business Premium, you have basic sensitivity labels but not the full Purview suite.
Ongoing Governance
Fixing permissions isn't a one-time job. New sites get created, people join and leave, sharing happens daily. You need ongoing governance to maintain the clean state you've worked to achieve.
Quarterly access reviews — review memberships on sensitive sites and groups
Sharing reports — monitor for new overshared content monthly
Site lifecycle management — archive or delete sites that are no longer active
Training — help staff understand that sharing decisions have consequences, especially with Copilot active
Incident process — have a clear process for what to do when someone reports that Copilot surfaced content they shouldn't have seen
The Bottom Line
Copilot doesn't create new security holes. It exposes existing ones — fast. The permissions problems in your SharePoint environment were always there. Copilot just makes them visible and consequential in a way they weren't before.
The good news: fixing these problems improves your security posture regardless of whether you deploy Copilot. Clean permissions, proper classification, and ongoing governance are things every organisation should have in place. Copilot just provides the urgency to actually do the work.
For a step-by-step deployment process that includes all this readiness work, see our Copilot deployment guide. For a broader view of what Copilot is and how it fits into your M365 environment, start with our plain-English Copilot guide or our earlier piece on how Frontrow rolls out Copilot.
We'll be publishing a detailed SharePoint permissions management guide in the coming weeks — if that's a topic you need help with now, don't wait for the article.
Need a Permissions Audit?
Frontrow Technology runs SharePoint permissions audits and Copilot readiness assessments for Australian businesses. We'll tell you exactly what state your permissions are in, what needs fixing, and how long it'll take — before you commit to Copilot licences.
It's a core part of our Microsoft 365 managed services and security uplift work.
Get in touch if you want an honest assessment of whether your environment is ready for Copilot — or if you already know it's not and need help sorting it out.

