Skip to main content
Question

Microsoft 365 Copilot Cowork - Long-lived connection requirements

  • May 25, 2026
  • 4 replies
  • 338 views

agus.rachman-0f6ca53d

In our environment, we found that M365 Copilot Cowork is not working when user’s connection is protected behind Netskope. Other customers using Netskope seems to be reporting the same issue as well.

Microsoft’s documentation on network requirements for Copilot Cowork has been published here Cowork network endpoints (Frontier) | Microsoft Support and they cited requirements around supporting long-lived connection. Microsoft support has also shared an internal document that mentioned about the use of Server-Sent Events--which based on Internet research is not something SASE/SWG products support by default.

Do you have a recommended configuration that we can use to make Copilot Cowork to work behind Netskope? Any plan to make this configuration to be part of the standard M365 policy from Netskope so that we don’t need to request a configuration change in our company? 

4 replies

lrichman-13d4f4a3

Hey there, I am not sure if you’re facing the same issue, but our users with Cowork (frontier) access were encountering their tasks under ‘recent’ or ‘scheduled’ not loading when proxied through Netskope. Disabling Netskope allowed those to load instantly. All SSL bypasses recommended by Microsoft were not working, so I consulted with Netskope support and they had me add the following URLs to a SSL decryption policy set to ‘do-not-decrypt’. This resolved the tasks not loading in Cowork Frontier in the Copilot website. 

 

If you’re using Copilot desktop app on Windows devices, I was able to get this working through a custom certificate-pinned app bypassed from steering. For this bypass, I just used the process names: m365copilot.exe, msedgewebview2.exe. You may not need to add this if the SSL decryption policy works fine. Let me know if any of these help!

 

Domains added to SSL Do-Not-Decrypt policy: 

copilot.cloud.microsoft

api.securitycopilot.microsoft.com

prod.cds.securitycopilot.microsoft.com

*.gateway.prod.island.powerapps.com

*.copilot.microsoft.com

*.copilot.com

copilotweb.production.portalrp.azure.com


agus.rachman-0f6ca53d

Thank you for the suggestion, we’ve managed to get it working by applying ssl decrypt bypass to *.gateway.prod.island.powerapps.com only.

 

However, the problem is Microsoft documentation talks only talks about “no absolute-lifetime timeout on streaming connections (or set the limit to 30 minutes minimum)” and we need to find ways to implement this with Netskope, else we have to justify why ssl decrypt bypass is required to our security architecture team.


lrichman-13d4f4a3

I don’t believe Netskope supports any configuration of absolute-lifetime timeout settings for connections proxied through the Netskope cloud. I haven’t heard or seen this configuration before, so I am unsure if that can be configured on the Netskope backend to accommodate this Microsoft recommendation. This can likely be disregarded if Netskope doesn’t apply any absolute-timeouts. 

 

I would stick with the SSL decryption policy and justify the implementation to the security team as required for business functionality. Copilot uses Web Sockets which are not gracefully handled by SWG/CASB/DLP inspection services, as documented in the below Microsoft article. As someone on the InfoSec side, this configuration is required if the business wants to use the latest Copilot modules and capabilities. Rely on Purview DLP capabilities for monitoring Copilot conversations, bypass through Netskope so the app actually works. 

https://learn.microsoft.com/en-us/microsoft-365/enterprise/network-intermediation?view=o365-worldwide


agus.rachman-0f6ca53d

Thank you for the input. Netskope engineer suggested an approach to bypass based on HTTP header used by the long lived connection traffic, this way we’re doing very selective bypass vs. bypassing all traffic going to the documented destination.

 

HTTP Header Profile with Real-Time Policy

  1. Create an HTTP Header Profile matching the following request header:
    • Header name: Accept
    • Value: text/event-stream
  1. Please refer to the attached screenshot for reference.
  2. Create a Real-Time Policy with the following configuration:
    • Add criteria: HTTP Header — select the profile created in Step 1.
    • For the destination, create a custom URL list and custom category for the domain *.gateway.prod.island.powerapps.com, then use that custom category as the destination.
    • Set the policy action to Bypass.
    • Ensure this bypass policy is placed at the top of the policy order so it takes precedence over any policies that subject traffic to content inspection.

 
Important considerations:

  • Bypassed traffic will skip content inspection — activity detection, DLP, and TSS will not be available for bypassed requests.
  • The HTTP header match is granular and will only apply to requests containing the specified header for that domain.
  • Traffic that is policy-bypassed does not generate Skope IT events.