SearchLeak: Dissecting the M365 Copilot One-Click Exfiltration Chain

Great post. We saw a similar issue in our testing lab. The behavioral approach is definitely the way to go since the domain reputation is inherently trusted. We're also using conditional access policies to limit Copilot access to managed devices only, which helps mitigate the risk of compromised credentials being used from untrusted endpoints.

The scariest part is the indexing of MFA codes. That implies the AI agent has way too much read access to inbox content. I'd recommend admins review their 'Graph Explorer' permissions immediately. We're stripping 'Mail.Read' and 'Calendars.Read' from the service principal used by Copilot until the patches are fully verified across our tenant.

Solid KQL snippet. I'd add a join to IdentityLogonEvents to correlate the ClientIP with recent risky sign-ins. If you see a high-volume Copilot search right after a 'Impossible Travel' alert, you know you're breached. Traditional EDR won't catch this since it's living entirely in the browser/SaaS layer.

Valid concerns. Beyond permissions, we're focusing on restricting ingestion at the content level. You can use DLP policies to block specific sensitive info types from appearing in Copilot responses. While it doesn't fix the indexing delay, it stops the exfiltration at the output stage. To audit your current Copilot DLP rules, use this snippet:

Get-DlpCompliancePolicy | Where-Object {$_.Name -like "*Copilot*"}

Has anyone tested if file-type exclusions in the admin center actually impact the indexing delay?

Valid concerns. While detection is key, prevention via strict segmentation is better. Information Barriers can ensure that even if Copilot is compromised, it cannot bridge data between isolated business units. This stops the 'one-click' exfiltration across departmental lines. You can verify your barrier groups using this command:

Get-InformationBarrierPolicy | Select-Object Name, State, AssignedSegments

Configuring these segments adds a critical layer of isolation that pure permission reviews might miss.

Great breakdown. From a red team perspective, the trusted domain bypass is the most dangerous vector because it slips past standard defenses. However, we've also found that even if the exploit is patched, the root cause often remains: overly permissive SharePoint indexing. You should audit which sites Copilot is actually allowed to read from and ensure external sharing isn't exposing data to the index.

Get-SPOSite -Limit All | Where-Object {$_.SharingCapabilities -ne 'Disabled'} | Select-Object Url, SharingCapabilities

Building on the containment discussion, if you can't patch immediately, consider disabling Copilot for privileged users as a stopgap. You can target specific security groups via PowerShell to limit the blast radius while you audit Graph permissions:

$groupId = "Your-Privileged-Group-ID"
Update-MgBetaAdminCopilot -DisableForGroupId $groupId


It’s a temporary fix, but it buys time to adjust DLP rules without locking everyone out.

Great discussion. While detection is vital, implementing rate-limiting on the specific Search API endpoints can effectively throttle large-scale exfiltration attempts even if the chain executes. I also recommend auditing your custom connectors; often, third-party data sources have looser permissions than native M365 data. If you need to investigate historical search patterns, try this snippet to isolate bulk queries:

Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -Operations "Search" -ResultSize 5000 | Group-Object UserIds | Where-Object {$_.Count -gt 100} | Select-Object Name, Count

Just ensure you're filtering for the Copilot workload specifically to reduce noise.