Microsoft 365 Copilot is not a search engine with a chat interface bolted on — it is an amplifier for whatever permission posture your tenant already has. Every broken inheritance, every "Everyone except external users" share, every anonymous link created in a hurry three years ago becomes instantly queryable the moment a user gets a Copilot license. Security teams that treat Copilot as a licensing exercise discover this the hard way. This article walks through how Copilot actually accesses your data, why oversharing in SharePoint and Teams is the central risk, how to discover shadow AI alongside it, and what Microsoft Purview's DSPM for AI, sensitivity labels, and DLP can and cannot do — ending with a practical readiness checklist.
How Copilot inherits permissions via Microsoft Graph
The single most important architectural fact about Copilot is that it has no permissions of its own. When a user prompts Copilot, the request is resolved through the Copilot semantic index, which is built on top of Microsoft Graph. Grounding data — the documents, emails, chats, and meeting transcripts Copilot uses to construct an answer — is retrieved under the user's own identity and access token. As Microsoft's own privacy documentation states plainly, Copilot "only surfaces organizational data to which individual users have at least view permissions."
This sounds reassuring until you think about what "view permissions" actually covers in a typical tenant:
- SharePoint sites where permissions were broken years ago and never reviewed
- Teams channels that added entire distribution groups for a project that ended in 2022
- OneDrive files shared with "anyone in the organization" links
- Sites accessible to "Everyone except external users," a group that includes every employee and often every guest
Copilot does not bypass access control. It industrializes it. A file that was technically accessible but practically invisible — buried three levels deep in a site nobody browses — is now one natural-language prompt away from being quoted verbatim in a response. The semantic index also means users no longer need to know a file exists to find it; they need only describe its content. Salary spreadsheets, M&A drafts, HR investigation notes: if the ACL says the user can read it, Copilot will summarize it.
Why oversharing becomes a Copilot risk specifically
Oversharing has existed in SharePoint since before Teams. What changed is the cost of discovery. As MyWorkDrive puts it, Copilot oversharing is "when Copilot surfaces files a user can technically open but was never meant to see." Traditional search required intent and effort — you had to go looking. Copilot collapses that to a single prompt like "what do we know about Project Nightingale?" asked out of idle curiosity.
Microsoft has acknowledged this is the most common deployment blocker, and its tooling response has come in stages. Restricted SharePoint Search (March 2024) was the emergency brake: it limits Copilot and org-wide search to an allowlist of up to 100 sites while you remediate. Microsoft has been explicit that it is a stopgap, not an end state. The longer-term answer is SharePoint Advanced Management (SAM), which — importantly — has been bundled with Microsoft 365 Copilot licenses since January 2025. SAM gives you:
- Data access governance reports — visibility into sites with oversharing signals: "Everyone except external users" access, high volumes of sharing links, public team exposure.
- Site access reviews — delegated, recurring reviews where site owners attest that membership and permissions are still appropriate.
- Restricted Access Control (RAC) — locks a site to a specific group so even users holding a sharing link are denied unless they are members. RAC is your hard control for genuinely sensitive sites.
- Restricted Content Discoverability — keeps a site's content out of Copilot and org-wide search results while leaving direct access intact, useful as a transitional measure.
The mental model for security teams: Copilot didn't create your oversharing problem, it just made it observable and exploitable at scale. As one practitioner analysis frames it, "Copilot does not break security. It shows where it was already broken."
Shadow AI: the parallel discovery problem
While you govern the sanctioned Copilot, your users are already using unsanctioned ones. Shadow AI — personal ChatGPT accounts, browser extensions, OAuth-connected AI plugins, unapproved Copilot Studio agents — is a subset of shadow IT with a worse blast radius, because whatever is pasted into these tools leaves your tenant boundary entirely.
Microsoft's discovery answer is Defender for Cloud Apps (MDA), which maintains a catalog of over a thousand generative AI apps with risk scores and lets you tag apps as sanctioned or unsanctioned. Unsanctioned apps can then be blocked at the network edge through Defender for Endpoint integration, as documented walkthroughs show. The workflow is: discover via MDA's generative AI app dashboard, triage by usage volume and risk score, sanction the ones you can govern, and block the rest — then watch for the OAuth grants, since many shadow AI tools ride in through consented third-party apps rather than websites.
Shadow AI discovery matters to your Copilot rollout for a strategic reason: a sanctioned, governed Copilot is your best argument against unsanctioned alternatives. Users who have a capable, approved tool have less reason to paste documents into a personal chatbot.
Microsoft Purview DSPM for AI
Data Security Posture Management for AI is Purview's control center for exactly this problem set. Per Microsoft Learn, it organizes around three pillars: recommendations (one-click policies to close common gaps), reports (activity and risk views across Copilot and other AI apps), and data assessments (on-demand scans that flag where sensitive data is exposed to AI surfaces).
The practically important capabilities:
- Pre-built one-click policies that capture Copilot prompts and responses containing sensitive data types (credit cards, health data, custom SITs) into Audit and Activity Explorer — this is how you build the evidence trail for regulators and internal audit.
- Oversharing assessments that correlate sensitive data discovery with the permission state of the sites holding it, surfacing "sensitive AND broadly accessible" intersections — precisely the files Copilot will surface first.
- AI observability across third-party models — DSPM for AI covers not just M365 Copilot but other generative AI apps, giving one pane for the sanctioned and unsanctioned estate. The newer Purview DSPM experience announced at the end of 2025 consolidates this further with enhanced posture reporting and Security Copilot agents for triage.
A note on scope: DSPM for AI tells you where your posture is bad. It does not fix permissions for you — that remains a SharePoint/SAM and site-owner problem. Treat it as the measurement layer, not the remediation layer.
Sensitivity labels and DLP: the enforcement layer
Sensitivity labels are the one control that travels with the content. A file labeled "Confidential — Finance" keeps its encryption and usage restrictions regardless of where it's copied. Critically for Copilot: label inheritance works in both directions. When Copilot generates a new document grounded in labeled sources, the output inherits the most restrictive applicable label. And with the right configuration, Copilot can be prevented from processing content whose labels enforce encryption the requesting user isn't authorized for — meaning label-based access control becomes a Copilot filter, not just a watermark.
The prerequisite is unglamorous: labels only protect what's labeled. If your tenant has 4% label coverage and an auto-labeling policy that's been "in simulation mode" for a year, labels are decorative. Before Copilot, get auto-labeling (both client-side service-based and at-rest policies for SharePoint/OneDrive) actually enforcing on your high-value data classes.
DLP for Copilot closed a gap that mattered a lot in early deployments: Purview DLP policies can now target the Microsoft 365 Copilot location directly, preventing Copilot from processing items carrying specified sensitivity labels. Combined with endpoint DLP (blocking pastes of labeled content into browser-based AI tools) and browser/session controls via Defender for Cloud Apps, this forms the containment ring around both sanctioned and unsanctioned AI use. Microsoft's Copilot readiness guidance from Ignite 2025 ties these pieces together explicitly.
Pre-deployment readiness checklist
For security teams approaching a Copilot rollout, in rough execution order:
- Baseline discovery. Run Purview DSPM for AI data assessments and SAM data access governance reports. Quantify: sites shared with "Everyone except external users," anonymous links, sensitive SITs on overshared sites. This is your business case and your before/after metric.
- Stand up Restricted SharePoint Search if remediation will take more than a few weeks — buy time with the 100-site allowlist rather than blocking the rollout entirely.
- Remediate the worst intersections first. Sensitive + broadly shared gets fixed before anything else: apply Restricted Access Control to crown-jewel sites, kill stale org-wide links, fix broken inheritance on HR/Finance/Legal sites.
- Operationalize site access reviews. Recurring, owner-attested reviews via SAM — oversharing regrows within a quarter if remediation is a one-time project.
- Get labels enforcing. Publish a minimal label taxonomy, enable auto-labeling for your top sensitive information types, and verify label inheritance behavior in Copilot responses during pilot.
- Configure DLP for the Copilot location, plus endpoint DLP rules blocking labeled content from flowing to unsanctioned browser AI tools.
- Enable DSPM for AI one-click policies so prompts and responses with sensitive data are captured in Audit from day one — you want the telemetry before you need it.
- Discover and posture shadow AI via Defender for Cloud Apps: sanction what you'll govern, block what you won't, audit OAuth grants.
- Pilot with a instrumented cohort. 50–200 users across departments, with Activity Explorer and DSPM reports reviewed weekly. Oversharing findings in the pilot tell you what enterprise-wide rollout will look like.
- Define the ongoing operating model. Who owns access review completion? Who triages DLP-for-Copilot incidents? What's the SLA for a site owner to respond to an oversharing finding? Copilot governance is a program, not a project.
The bottom line
Copilot's security model is simple and unforgiving: it surfaces exactly what your permissions allow, at machine speed, to anyone who asks. The organizations that succeed treat the Copilot rollout as a forcing function to fix a decade of SharePoint permission debt — with DSPM for AI as the measurement layer, SAM as the remediation engine, labels and DLP as the enforcement layer, and Defender as the watch on everything happening outside the sanctioned estate. Skip the governance work, and Copilot will still deploy fine. It will just spend its days helpfully summarizing things your users were never supposed to see.