How Enterprise Administrators Configure Data Access Permissions and Sensitivity Labels in SharePoint Prior to Rolling Out Microsoft 365 Copilot

Deploying Microsoft 365 Copilot requires enterprise administrators to address content hygiene and access governance before granting licenses to end users. While Copilot strictly operates within existing Microsoft 365 security perimeters and access control lists (ACLs)—ensuring users cannot query information they do not have permission to view—its powerful semantic search and natural language synthesis amplify the discoverability of previously overlooked files. In organizations with legacy permissions debt, confidential documents such as executive compensation plans, acquisition memos, or customer personally identifiable information (PII) stored in sites with broad access like "Everyone except external users" (EEEU) can be unintentionally surfaced in conversational answers. To prevent data leakage and maintain compliance, administrators must audit overshared repositories, remediate tenant access permissions, deploy container- and item-level Microsoft Purview sensitivity labels, and establish temporary guardrails like Restricted SharePoint Search. This guide outlines the end-to-end technical configuration required to secure SharePoint data prior to rolling out Microsoft 365 Copilot.

Understanding the Copilot Grounding and Security Model

Microsoft 365 Copilot interacts with organizational data through a process known as Retrieval-Augmented Generation (RAG). When a user submits a prompt, Copilot does not query an isolated training corpus; instead, it uses the Microsoft Graph and the Semantic Index for Copilot to identify relevant organizational content, packages those snippets into a grounding context, and passes them to the large language model (LLM) to formulate a response.

How Access Boundaries Operate

Copilot operates strictly within the security context of the user executing the prompt:

• Inherited User Rights: Copilot has no elevated service-account privileges. If a user cannot access a SharePoint document via the web browser, direct URL, or standard SharePoint search, Copilot cannot access or synthesize that document for that user.
• The Discoverability Gap: In traditional SharePoint environments, users rarely discover obscure files stored in misconfigured libraries because keyword search requires specific terms or knowledge of the file name. Copilot, by contrast, interprets intent and semantics. If an employee asks, "What are the latest salary adjustment proposals across engineering?", Copilot searches indexed documents that the user technically has read rights to, retrieves the data, and presents a direct summary.
• Security Boundary Enforcement: Copilot honors security controls configured across Microsoft Entra ID, SharePoint Online, and Microsoft Purview. However, it does not correct improper permissions. Security teams must ensure that "read" access represents genuine business authorization.

Rights Management Services (RMS) and the EXTRACT Right

When interacting with encrypted files, Copilot enforces Rights Management Services (RMS) permissions. For Copilot to read, parse, and extract information from a protected document to answer a prompt, the requesting user must possess the EXTRACT (Copy) usage right:

If a sensitivity label applies encryption that denies the EXTRACT right to a group of users, those users cannot use Copilot to summarize or interrogate those specific documents, even if they can view the rendered document in Word or Excel.

Step 1: Auditing SharePoint Permissions and Identifying Overshared Content

Before modifying permissions or applying restrictive policies, administrators must establish visibility into existing access structures. The primary risks stem from broad domain-wide groups, orphaned team sites, and unmanaged sharing links.

Utilizing Data Access Governance (DAG) Reports

SharePoint Data Access Governance (DAG) reports, available in the SharePoint Admin Center under Reports > Data access governance, provide automated insights into tenant-wide sharing patterns. Administrators should prioritize three specific report categories:

1. "Everyone except external users" (EEEU) Reports: Identifies all SharePoint sites where the EEEU claim has been added to site permissions (such as Site Members or Site Visitors). These sites are accessible to every internal employee, making them the primary source of unintended Copilot data exposure.
2. Sharing Links Reports: Identifies sites containing the highest volume of "Anyone with the link" (anonymous) or "People in your organization" (tenant-wide internal) sharing links created in the past 30 days.
3. Sensitivity Labels Applied to Files Reports: Cross-references sites storing high concentrations of unlabeled or sensitive files to pinpoint governance blind spots.

DAG Administrative Audit Workflow:
1. Navigate to SharePoint Admin Center -> Reports -> Data access governance
2. Run "Sharing links" report -> Filter by "People in your organization"
3. Run "Everyone except external users" report -> Sort by total file count
4. Export high-risk site inventories to CSV for security review

Reviewing High-Risk Repository Attributes

When evaluating DAG export data, administrators should categorize sites based on content sensitivity and existing membership:

• Executive & HR Repositories: Legal, HR, Finance, and M&A sites must be inspected for inherited parent permissions and broad security group memberships.
• Public vs. Private Microsoft 365 Groups: When users create Microsoft Teams or Microsoft 365 Groups, the default setting is often "Public," granting any tenant user read and write access to the associated SharePoint team site. These must be identified and converted to "Private."
• Broken Permission Inheritance: Subfolders and individual document libraries with unique, broken permissions often hide sensitive files inside otherwise benign departmental sites.

Step 2: Remediating Permissions and Implementing Access Guardrails

Once overshared repositories are identified, administrators must remediate open access and apply structural controls to prevent future permission creep.

Eliminating Broad Groups and Revoking Open Sharing Links

Remediation should follow a prioritized sequence:

1. Remove EEEU Claims: Remove "Everyone except external users" from the Site Members, Site Visitors, and document-level permission sets of any site containing proprietary, internal-only, or sensitive content.
2. Standardize Default Sharing Link Types: In the SharePoint Admin Center under Policies > Sharing, adjust the default sharing link type from "People in your organization" to "Specific people (only the people the user specifies)." This prevents users from inadvertently creating tenant-wide access links when sharing files with colleagues.
3. Set Link Expiration Windows: Enforce automatic expiration policies for guest and anonymous sharing links (for example, requiring re-authentication after 30 to 90 days).

Deploying SharePoint Advanced Management (SAM) Controls

For organizations with SharePoint Advanced Management (SAM) licenses, administrators can enforce centralized access boundaries without relying solely on individual site owners:

• Restricted Access Control (RAC) for SharePoint Sites: RAC allows administrators to restrict access to a SharePoint site to members of specified Microsoft Entra ID security groups or Microsoft 365 groups. Even if an individual user has direct file permissions or belongs to a nested group, access is denied unless the user belongs to the designated RAC group.
• Restricted Content Discovery (RCD): RCD enables administrators to place high-risk or unverified sites into a discovery quarantine. When RCD is active on a site, its contents are hidden from tenant-wide search and Copilot responses, while existing authorized site members retain direct access. This allows security teams to isolate unvetted sites without disrupting ongoing daily work.
• Site Access Reviews: Administrators can initiate automated access review campaigns that require site owners to periodically attest to their membership lists, automatically revoking access for dormant or unauthorized users.

Implementing Restricted SharePoint Search (RSS) as a Temporary Circuit Breaker

In large enterprises with thousands of SharePoint sites, completing a comprehensive permissions cleanup can take months. To prevent delays in rolling out Copilot licenses, Microsoft provides Restricted SharePoint Search (RSS) as an interim administrative control.

How Restricted SharePoint Search Functions

When RSS is enabled:

• Enterprise search and Microsoft 365 Copilot are restricted to an Allowed List of up to 100 curated SharePoint sites.
• Copilot continues to access the user's personal OneDrive, email messages, Teams chats, calendar events, and sites the user frequently visits or explicitly owns.
• Content stored in the thousands of uncurated SharePoint sites is excluded from Copilot grounding and organization-wide search, eliminating the risk of Copilot pulling data from unvetted repositories.

Configuring RSS via SharePoint Online PowerShell

Restricted SharePoint Search is managed using the SharePoint Online PowerShell module:

# Connect to your SharePoint Online tenant admin endpoint
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

# Check the current status of Restricted SharePoint Search
Get-SPOTenantRestrictedSearchMode

# Enable Restricted SharePoint Search mode
Set-SPOTenantRestrictedSearchMode -Mode Enabled

# Add approved enterprise sites to the Allowed List (up to 100 sites)
Add-SPOTenantRestrictedSearchAllowedList -SitesList @(
    "https://contoso.sharepoint.com/sites/CorporateComms",
    "https://contoso.sharepoint.com/sites/CompanyPolicies",
    "https://contoso.sharepoint.com/sites/ITHelpdesk",
    "https://contoso.sharepoint.com/sites/EmployeeHandbook"
)

# View all currently allowed sites
Get-SPOTenantRestrictedSearchAllowedList

Transitioning Away from RSS

Restricted SharePoint Search is designed as a temporary bridge, not a permanent architecture. While RSS protects against data leakage from unvetted sites, it also limits Copilot's ability to provide cross-functional insights across legitimate project repositories. Once Data Access Governance reports confirm that site permissions have been cleaned up and sensitivity labels are enforced, administrators should disable RSS to unlock Copilot's full organizational value:

# Disable Restricted SharePoint Search once governance remediation is complete
Set-SPOTenantRestrictedSearchMode -Mode Disabled

Step 3: Designing and Deploying Microsoft Purview Sensitivity Labels

While SharePoint permissions define who has access to a site or folder, Microsoft Purview sensitivity labels define what the content is and enforce persistent protection that travels with the data wherever it is stored, shared, or processed by AI.

Container-Level Sensitivity Labels

Container-level labels apply governance settings directly to SharePoint sites, Microsoft 365 Groups, and Microsoft Teams. Before creating container labels, ensure the feature is enabled in your tenant via PowerShell (Set-ExecutionPolicy RemoteSigned; Import-Module Microsoft.Graph; Connect-MgGraph) and Microsoft Entra ID.

Container labels enforce three primary controls relevant to Copilot readiness:

1. Privacy Settings (Public vs. Private): Enforcing "Private" ensures that new team sites cannot be created with open tenant-wide access.
2. External Sharing Controls: Setting the label to "Only people in your organization" or "Existing guests" prevents external data leakage on sensitive collaboration sites.
3. Conditional Access and Unmanaged Device Policies: Restricting access to web-only or blocking access from non-compliant devices ensures Copilot cannot be accessed from untrusted endpoints interacting with sensitive sites.

Item-Level Sensitivity Labels and Encryption

Item-level labels classify and protect individual Word, Excel, PowerPoint, and PDF files. Administrators configure these labels in the Microsoft Purview compliance portal under Information protection > Labels.

A standard enterprise classification schema typically includes:

• Public: Non-sensitive data intended for public consumption (no encryption).
• General: Everyday business data shared internally (no encryption or basic internal rights).
• Confidential: Sensitive business data (financial reports, client strategies). Configured with Azure Information Protection encryption, restricting access to authenticated organizational employees with EXTRACT rights.
• Highly Confidential: Critical intellectual property, executive compensation, M&A filings. Configured with strict encryption, restricting access to designated named users or security groups. In specific scenarios, the EXTRACT right may be removed to explicitly block AI synthesis and clipboard copying.

Copilot Sensitivity Label Inheritance

When Microsoft 365 Copilot synthesizes information to generate a new document, email draft, or summary, it adheres to strict label inheritance rules:

• Single Source Reference: If Copilot references a single document labeled Confidential, any new file generated by Copilot from that interaction automatically receives the Confidential label and its associated encryption settings.
• Multiple Source References: If Copilot combines content from multiple sources with differing classifications (for example, one document labeled General and another labeled Highly Confidential), Copilot automatically applies the most restrictive label (Highly Confidential) to the output.
• Telemetry and Visibility: Copilot displays the applied sensitivity label directly in the user interface, ensuring users are immediately aware of the data's classification level.

Configuring Purview Auto-Labeling Policies

Manual labeling relies on end-user compliance, which frequently leaves gaps. To ensure consistent coverage prior to rolling out Copilot, administrators should deploy both client-side and service-side auto-labeling policies.

Client-Side Auto-Labeling

Configured within the label definition in Microsoft Purview:

• Prompts or automatically applies labels when users author documents in Word, Excel, or PowerPoint based on detected Sensitive Information Types (SITs) such as credit card numbers, tax identifiers, or custom regular expressions.
• Provides immediate user education at the moment of document creation.

Service-Side Auto-Labeling (At-Rest Inspection)

Service-side auto-labeling operates at the tenant infrastructure level, scanning files stored across SharePoint Online and OneDrive:

1. In the Microsoft Purview portal, navigate to Information protection > Auto-labeling.
2. Create a new policy targeting SharePoint sites and OneDrive accounts.
3. Define the detection rules using built-in SITs (financial records, health data) or Trainable Classifiers (source code, legal agreements).
4. Run the policy in Simulation Mode for at least 7 to 14 days to review matches, verify accuracy, and avoid unintentional over-labeling.
5. Once simulation results match expectations, turn the policy on to automatically apply labels and encryption to historical data at rest.

Implementation Roadmap: Phased Pre-Rollout Governance

To structure the rollout effectively, administrators should follow a phased operational schedule:

Validating Security Boundaries and Ongoing Governance

Before opening Copilot access to the broader enterprise, administrators must systematically validate that security boundaries function as intended.

Synthetic User Testing Scenarios

Security teams should establish test accounts with distinct departmental personas (for example, standard Sales, standard Engineering, and HR Specialist accounts) to perform prompt validation:

• Cross-Departmental Probing: From the standard Sales test account, submit targeted Copilot prompts such as "Summarize the upcoming executive reorganization plan" or "Show me recent compensation reviews." Confirm that Copilot returns no data and indicates that it cannot find relevant information.
• Encrypted Document Probing: Test prompts against documents where the user has VIEW permissions but lacks EXTRACT permissions. Confirm that Copilot refuses to extract or summarize the text.
• Inheritance Verification: Ask Copilot to draft a memo using a Confidential document as a reference, and verify that the generated output automatically retains the Confidential sensitivity label.

Monitoring Through Microsoft Purview AI Hub

Microsoft Purview provides the AI Hub (located in the Purview compliance portal), offering dedicated telemetry for Microsoft 365 Copilot interactions:

• Sensitive Data Activity: View real-time dashboards showing which sensitive information types and sensitivity labels are being referenced in Copilot user prompts and generated responses.
• Policy Violations: Set up Data Loss Prevention (DLP) alerts to detect when users attempt to share or export Copilot responses containing sensitive data to unauthorized locations.
• Audit Logging: Query the unified audit log using the CopilotInteraction record type in Purview Audit to investigate specific user prompts, referenced file URIs, and applied labels for compliance auditing.

By combining proactive permission remediation in SharePoint, targeted controls like Restricted SharePoint Search, persistent Microsoft Purview sensitivity labels, and continuous telemetry monitoring, enterprise administrators can successfully eliminate data leakage risks and ensure a secure, compliant rollout of Microsoft 365 Copilot.