IT 幫 M365 連接器設了 VPN 限制，結果全公司都連不上——問題出在請求根本不是從員工的電腦發出的

公司的資安團隊照著標準流程，替 Microsoft 365 連接器設定了一條 Conditional Access 規則：只允許公司 VPN 或辦公室網段的請求通過。這是他們對所有企業應用程式的例行做法，理論上滴水不漏。結果政策一上線，所有人的 Cowork 連接器同時斷線，包含正在辦公室裡、確實連著公司 VPN 的員工。

問題不在政策寫錯，而在一個容易被忽略的架構事實：Conditional Access 檢查的是「請求從哪個網路位置發出」，但 M365 連接器的請求，從來就不是從員工的電腦發出的。

連接器的請求，來源永遠是 Anthropic 的伺服器

官方安全指南把這件事講得很直白：「伺服器端的請求一律顯示為來自 Anthropic 的 IP 範圍」。當你在 Cowork 裡用 M365 連接器搜尋郵件或讀取 SharePoint 文件時，實際發出 API 呼叫的不是你桌機的瀏覽器，而是 Anthropic 後端的伺服器代表你去呼叫 Microsoft Graph API。從 Microsoft 那一端的視角看，這個請求的來源 IP，永遠是 Anthropic 的伺服器範圍，跟你人在哪裡、用什麼網路完全無關。

這代表任何基於「位置」或「網路」的 Conditional Access 規則，對連接器請求來說天生就是失效的——不是規則設錯，而是這類規則本來就假設請求來自使用者的裝置，而連接器架構從一開始就不是這樣運作。MFA 跟以群組為基礎的政策不受影響，因為那些檢查的是使用者身份本身，不是網路位置。

更麻煩的是「失效」不等於「無害跳過」，而是「全面封鎖」

如果只是規則不生效、連接器照常運作，頂多是資安團隊少了一層防護，稱不上緊急事故。但實際情況往往更棘手：因為所有連接器流量共用同一段來自 Anthropic 的 IP 範圍，一旦公司的 Conditional Access 規則把「非公司網段」設為封鎖而非略過，整個組織的 M365 連接器就會一次性、全面停擺——不是某個員工連不上，而是所有用這個連接器的人同時斷線，而且症狀看起來會很像「連接器本身壞了」，容易讓 IT 團隊往錯誤的方向排查。

另外兩個容易被誤判成 bug 的架構限制

權限範圍上，連接器只能看到使用者原本就有權限存取的內容——沒辦法繞過 SharePoint 的共用設定或資料夾權限，也看不到其他使用者的私人檔案或郵件；但共用信箱的委派存取是允許的，且僅限唯讀。這代表連接器不是額外的存取管道，而是使用者既有權限的延伸，這點常被誤解成「連接器有自己獨立的權限系統」。

另一個容易誤判的細節是封存信箱（Online Archive）：官方文件說明「郵件搜尋涵蓋每個使用者的主要信箱……以及他們有權限的共用信箱，但不涵蓋獨立的線上封存信箱」。如果公司有郵件保留政策，會定期把舊郵件自動搬進封存信箱，這些郵件之後就搜尋不到了——使用者通常會以為是連接器漏掉了某封信，但其實是信本來就不在連接器能搜尋的範圍。裝置合規性政策也有類似的時間差：合規性是拿「當初建立連線的裝置」去檢查，不是拿「現在使用的裝置」，所以裝置不合規時，通常不是連線當下就被擋，而是第一次呼叫工具時才失敗，這種延遲會讓故障排查更難對上時間點。

這跟你的工作有什麼關係

如果你是負責設定企業連接器政策的人，這裡真正該調整的不是「把規則寫得更嚴」，而是先搞清楚哪一類 Conditional Access 規則對連接器架構有意義：身份驗證層（MFA、群組成員資格、裝置合規性）是有效的管控點，網路位置層對連接器請求沒有意義，設了也只會製造誤判的斷線事故。如果你已經因為連接器忽然全面斷線而在排查問題，第一件事應該是檢查是不是有任何基於 IP 或地理位置的政策套用在這個連接器上，而不是去查連接器本身的健康狀態。