How to Investigate a Copilot Data Leak Concern in Microsoft 365

You have heard concerns that Microsoft Copilot might expose sensitive company data to unauthorized users. These worries often stem from confusion about how Copilot accesses and presents information from Microsoft Graph, SharePoint, and other data sources. The root cause is usually a misunderstanding of Copilot data access controls rather than an actual data leak. This article explains the technical safeguards Microsoft has built into Copilot and provides a step-by-step method to investigate and confirm that your tenant data remains secure.

How Copilot Data Access Works in Microsoft 365

Copilot does not bypass existing security permissions. When a user asks a question in Copilot, the system retrieves data from Microsoft Graph based on the user identity and the sensitivity labels applied to the content. Copilot can only access data that the authenticated user already has permission to read through their existing Microsoft 365 role assignments and SharePoint site permissions. The system generates responses using this data without copying it to a separate storage location. Microsoft has published a white paper on Copilot data flow architecture that confirms all data processing occurs within the Microsoft 365 compliance boundary.

The primary concern about data leaks arises when an organization has not configured sensitivity labels, conditional access policies, or SharePoint site permissions correctly. If a user has read access to a sensitive document, Copilot will surface that document content in its response. The fix is not to disable Copilot but to audit and tighten existing permissions. Microsoft provides several tools to investigate and control what Copilot can access, including the Microsoft 365 admin center, Microsoft Purview, and PowerShell scripts.

Prerequisites for Investigating

Before you start, ensure you have a Microsoft 365 account with the Global reader role or the Compliance administrator role. These roles let you view data access settings without making changes. You also need access to the Microsoft 365 admin center and the Microsoft Purview compliance portal. If you plan to use PowerShell, install the Exchange Online PowerShell module and the Microsoft Graph PowerShell SDK.

Steps to Investigate Copilot Data Access in Your Tenant

1. Check Copilot data sources in the Microsoft 365 admin center
   Sign in to the Microsoft 365 admin center at admin.microsoft.com. Go to Settings > Org settings > Copilot. Click Data sources. Review the list of Microsoft Graph data sources that Copilot can read. By default, Copilot reads from Exchange Online, SharePoint Online, OneDrive for Business, and Microsoft Teams. If you see a data source that should be restricted, click it and select Block.
2. Audit Copilot activity in the Microsoft 365 audit log
   Go to the Microsoft 365 admin center > Security > Audit. Search for Copilot activity by selecting Activities > Copilot activities. Look for events like Copilot interaction, Copilot response generated, and Copilot data accessed. Filter by user, date range, and data source. This log shows exactly which data Copilot retrieved for each user query.
3. Review SharePoint site permissions for sensitive content
   In the SharePoint admin center, identify sites that contain sensitive data. Go to Active sites, select a site, and click Permissions. Check whether external users or broad groups like Everyone except external users have access. If you find over-permissioned sites, remove unnecessary users or groups. Copilot cannot access content that the user does not have permission to read.
4. Run a sensitivity label audit with Microsoft Purview
   In the Microsoft Purview compliance portal, go to Information protection > Sensitivity labels. Select a label and click Label settings. Verify that the label is published to the correct users and groups. Then go to Data classification > Content explorer to see which files have that label applied. Copilot respects sensitivity labels and will not surface content that the user does not have permission to decrypt.
5. Create a data loss prevention policy for Copilot
   In the Microsoft Purview compliance portal, go to Data loss prevention > Policies. Click Create policy. Choose Custom and select Copilot as the location. Define conditions such as content contains credit card numbers or content contains passport numbers. Set the action to Block access and notify the user. This policy prevents Copilot from generating responses that include sensitive data.
6. Use PowerShell to export Copilot activity logs
   Open Exchange Online PowerShell and run Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Operations CopilotInteraction, CopilotResponseGenerated. Export the results to a CSV file. Review the records for any queries that returned data the user should not have been able to access. This step helps identify permission gaps that need remediation.

If Copilot Still Shows Unexpected Data

Copilot returns data from a site where the user was removed

This situation usually occurs because the user cached data locally or the site permissions change had not propagated to all servers. Wait 24 hours for permission changes to replicate across the Microsoft 365 service. Then ask the user to close and reopen Copilot. If the issue persists, check whether the user has a direct permission assignment through a Microsoft 365 group or a Teams channel membership that still grants access.

Copilot generates responses that include external user data

External users with guest accounts in your tenant can ask Copilot questions. Copilot will only return data that the guest user has permission to read. If a guest user sees data they should not see, review the guest user permissions in Azure AD. Go to Azure AD > External identities > External collaboration settings. Ensure that guest user access is restricted to specific applications and sites. Also check whether the guest user has been added to any Microsoft 365 groups that contain sensitive content.

Copilot returns content from a deleted document

When a user deletes a document, it moves to the SharePoint recycle bin. Copilot can still access content in the recycle bin for 93 days. To prevent this, configure SharePoint retention policies that permanently delete content after a specified period. Go to the SharePoint admin center > Policies > Retention. Create a retention label that deletes content after 30 days and apply it to sensitive document libraries.

Copilot Data Access Controls: Admin Center vs Purview vs PowerShell

Item	Microsoft 365 Admin Center	Microsoft Purview	PowerShell
Primary function	View and block Copilot data sources	Create DLP policies and sensitivity labels	Export audit logs and automate permission checks
Granularity of control	Data source level	Content level with conditions	Event level and bulk operations
Requires admin role	Global admin or Global reader	Compliance admin or Information protection admin	Global admin or Exchange admin
Best for	Initial review and blocking broad data sources	Preventing specific sensitive data from appearing in Copilot responses	Investigating specific user queries and automating remediation

Microsoft 365 administrators should use all three tools together. Start with the admin center to block unnecessary data sources. Then use Purview to apply sensitivity labels and DLP policies. Finally, use PowerShell to audit Copilot activity and verify that permissions are correct.

Conclusion

You can now investigate a Copilot data leak concern by auditing data sources, permissions, and audit logs in the Microsoft 365 admin center and Microsoft Purview. The key action is to verify that sensitivity labels and SharePoint permissions are configured correctly rather than disabling Copilot entirely. Next, run the PowerShell script to export Copilot activity logs for the past 30 days and review the results for any unexpected data access. As an advanced tip, use the Microsoft Graph API to programmatically check permissions on every site in your tenant and generate a report of over-permissioned locations.