Microsoft Entra 的 2026 年 8 月發行浪潮進入最後一週，伴隨兩項看似無關、實則彼此相連的更新：兩者都凸顯了 Entra ID 的驗證基礎架構，如何成為更廣泛的 AI 與開發者生態系的關卡（gating factor）。

第一項是 Azure DevOps Remote MCP Server 的正式上市（general availability, GA）公告，儘管掛上 GA 標籤，卻附帶一項重大但書——Entra ID 的 OAuth 實作缺乏第三方 AI 程式碼助手連線所需的用戶端註冊機制支援。第二項則是 CVE-2026-69836（本週稍早揭露的最高嚴重性 Entra ID 遠端程式碼執行漏洞）利用狀態的最終確認。

以下是變更內容、為何重要，以及貴組織應如何因應。

1. Azure DevOps Remote MCP Server 達到 GA——但第三方 AI 用戶端無法連線

發布日期： 2026 年 8 月 5 日（GA 公告）；2026 年 8 月 21 日至 23 日廣泛報導 狀態： 正式上市（General Availability，附帶重大限制）

Microsoft 宣布 Azure DevOps Remote MCP Server 正式上市，透過可串流 HTTP（streamable HTTP）在 https://mcp.dev.azure.com/{organization} 提供 Microsoft 代管端點。此伺服器讓 AI 助手能存取 Azure DevOps 的工作項目（work items）、提取要求（pull requests）、存放庫（repositories）、Wiki 與管線（pipelines），無需每位開發者自行安裝與操作本機 MCP 伺服器。

問題所在：Entra ID 的 OAuth 缺口

這則 GA 頭條公告背後掩蓋了一項重大限制，連 Microsoft 自己的文件都予以承認：第三方 MCP 用戶端——Claude Desktop、Claude Code、ChatGPT 與 Cursor——無法連線至遠端伺服器，因為 Microsoft Entra ID 尚不支援這些用戶端所需的 OAuth 用戶端註冊機制。

此問題可拆解為兩項具體缺口：

  1. 動態用戶端註冊（Dynamic Client Registration, DCR）： 可讓第三方用戶端向 Entra ID 的授權伺服器自動註冊自身的機制。MCP 2026-07-28 規格已將 DCR 標記為淘汰，預計在 2027 年夏季之後移除。

  2. 用戶端 ID 中繼資料文件（Client ID Metadata Documents, CIMD）： MCP 規格中新的偏好機制，用戶端會在眾所周知的 URL（well-known URL）發布其註冊中繼資料。Entra ID 目前亦不支援此機制。

Microsoft 表示正與 Entra 團隊合作以啟用支援，但尚未公布時間表。Azure DevOps 團隊自己的部落格也證實，限制出在 Entra 這一側。

目前可正常運作的部分

Microsoft 的第一方用戶端無需額外設定即可連線：

  • 搭配 GitHub Copilot 的 Visual Studio Code
  • Visual Studio
  • Microsoft Foundry（透過其工具目錄）
  • Copilot Studio
  • GitHub Copilot CLI
  • GitHub Copilot 應用程式

這些用戶端使用 Microsoft 已在 Entra ID 中預先設定的已註冊 OAuth 應用程式身分。

目前無法運作的部分

依賴自行註冊或中繼資料探索的第三方 AI 程式碼助手，無法對 Entra ID 完成 OAuth 流程：

  • Claude Desktop 與 Claude Code（Anthropic）
  • ChatGPT（OpenAI）
  • Cursor

使用這些工具的開發者必須繼續執行本機 Azure DevOps MCP Server，這需要在每台開發者電腦上安裝與維護，並使用個人存取權杖（personal access tokens, PATs）進行驗證，而非 Entra ID。

永久限制：僅限 Entra 支援的組織

除了用戶端驗證缺口之外，遠端伺服器還有一項永久性的架構要求：Azure DevOps 組織必須由 Microsoft Entra 租用戶支援。使用 Microsoft 帳戶進行身分識別的獨立 Azure DevOps 組織不受支援，未來也不會支援——Microsoft 將此定位為 Entra 驗證架構的設計要求，而非暫時性限制。

擁有較舊獨立 Azure DevOps 租用戶、且想使用遠端 MCP 伺服器的組織，必須先遷移至 Entra 支援的組織。

為何這對身分識別團隊很重要

此情況之所以值得關注，是因為它將 Entra ID 的產品藍圖（roadmap）變成更廣泛 MCP 生態系的直接依賴。MCP 規格正從 Dynamic Client Registration 轉向 Client ID Metadata Documents，但 Entra ID 目前兩者皆不支援。這代表：

  • 使用非 Microsoft 工具的 AI 輔助開發工作流程在身分識別層就被阻擋，而非通訊協定層
  • 企業對 AI 程式碼工具的治理在代管端點只能服務 Microsoft 用戶端的情況下，變得更加困難，而非更容易
  • MCP 規格的轉型形成一個移動靶——等到 Entra 加入 DCR 支援時，規格可能已將其完全淘汰

對於標準化採用 Claude、ChatGPT 或 Cursor 進行 AI 輔助開發的組織而言，訊息很清楚：Entra ID 的 OAuth 能力就是瓶頸，而且目前沒有已公布的修復時間表。

貴組織應採取的行動

  1. 若您使用 Microsoft 第一方 AI 工具： 您可以立即採用遠端 MCP 伺服器。將端點 URL 加入您的用戶端設定，並確保您的 Azure DevOps 組織為 Entra 支援。
  2. 若您使用第三方 AI 工具（Claude、ChatGPT、Cursor）： 請繼續使用本機 Azure DevOps MCP Server。當 Entra ID 加入 CIMD 支援時再規劃轉移，但別抱太大期望——目前尚未公布時間表。
  3. 若您擁有獨立 Azure DevOps 組織： 若未來想使用遠端 MCP 伺服器，請遷移至 Entra 支援的組織。這是必要前提，而非暫時性限制。
  4. 身分識別管理員： 追蹤 Entra ID 的 OAuth 用戶端註冊產品藍圖。這現在是 MCP 互通性的關鍵因素，當您的開發者嘗試連線其 AI 工具時，他們一定會問起此事。

2. CVE-2026-69836：利用狀態最終確認——未遭利用

發布日期： 2026 年 8 月 20 日初次揭露；2026 年 8 月 21 日與 8 月 24 日狀態更正 狀態： 已由 Microsoft 完全緩解；未在實際環境中遭到利用

2026 年 8 月 24 日，Help Net Security 發布附時間戳記的更新，確認 CVE-2026-69836 的最終利用狀態。這是 Microsoft Entra ID 中於 8 月 20 日揭露的最高嚴重性（CVSS 10.0）遠端程式碼執行漏洞。

事發經過

此漏洞由 Robert Fitzpatrick（Microsoft 首席安全性工程師，Principal Security Engineer）發現，屬於 Entra ID 中不可信資料還原序列化（deserialization of untrusted data，CWE-502）問題，可能允許未經驗證的攻擊者在無需使用者互動的情況下，透過網路執行任意程式碼。Microsoft 給予 CVSS 3.1 最高分 10.0，攻擊向量為 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H。

Microsoft 的初始公告將利用狀態標示為「是」（Yes），引發安全性社群的高度關注。8 月 21 日，在 The Hacker News 詢問之後，Microsoft 將狀態更正為「否」（No）。8 月 24 日，最終確認出爐：

「Microsoft 發布 CVE-2026-69836 公告時，聲稱該漏洞已遭利用。此後，該公司將利用狀態改為『否』，並向 Help Net Security 確認此漏洞未在實際環境中遭到利用。」——Help Net Security，2026 年 8 月 24 日更新

MSRC 公告 JSON 現在包含這段摘要：「已將『Exploited』更正為『No』。此漏洞未在實際環境中遭到利用。此僅為資訊性變更。」

這代表什麼

  • 客戶無需採取任何行動——Microsoft 已在服務端完全緩解此漏洞。客戶無需部署任何修補程式、KB 或組態變更。
  • 沒有遭利用的證據——儘管最初標示為「已遭利用」，此漏洞實際上從未在實際環境中遭到利用。這項更正現在已是最終且經確認的狀態。
  • 透明度計畫發揮作用——Microsoft 發布此 CVE 純粹是基於其「Toward Greater Transparency: Unveiling Cloud Service CVEs」（邁向更高透明度：揭露雲端服務 CVE）計畫的透明度考量。對於由供應商在伺服器端修補的雲端服務，傳統的 CVE 揭露機制並不適用，但 Microsoft 仍選擇發布。
  • 仍建議進行盡職調查——雖然未發生任何利用行為，安全性團隊仍應依標準衛生習慣，檢視緩解前時間窗內的 Entra 登入記錄、稽核記錄與特殊權限角色指派是否有異常。

為何這波混淆很重要

初始的「已遭利用」標籤引發了安全性媒體（BleepingComputer、The Register、The Hacker News、CybersecurityNews）的大量報導。而「未遭利用」的更正卻未獲同等矚目，導致依賴初始報導運作的組織，可能抱持不精確的威脅認知。

對於依據初始「已遭利用」狀態啟動事件回應程序的組織而言，這項最終確認提供了結案：此漏洞真實且嚴重，但在任何利用行為發生之前，就已遭到攔截與修復。

共同主軸：Entra ID 作為平台守門員

連結這兩則故事的是，兩者都展現了 Entra ID 的能力——或能力不足之處——如何直接決定更廣泛生態系的成敗。Azure DevOps MCP Server 對第三方 AI 工具的可用性，並非受限於 MCP 通訊協定或 Azure DevOps API，而是受限於 Entra ID 的 OAuth 用戶端註冊支援。CVE-2026-69836 漏洞的影響之所以能被控制，靠的不是客戶的修補程式，而是 Microsoft 在其自身身分識別基礎架構中緩解問題的能力。

在這兩個案例中，Entra ID 都是守門員。當它正常運作時，下游一切正常。當它出現缺口時——無論是 OAuth 用戶端註冊還是還原序列化驗證——影響都會向外擴散至開發者工具、AI 代理程式與企業安全性態勢。

這就是雲原生身分識別的現實：身分提供者不只是驗證服務，更是平台依賴。建置在 Entra ID 之上的組織，不只要追蹤功能公告，也要追蹤缺口與限制。

值得關注的重要日期

  • 2026 年 9 月 1 日： Passkeys 成為 Entra ID 的預設；SMS/語音使用者開始自動啟用
  • 2026 年 9 月 18 日： Microsoft 為需要在 SMS/語音退役後繼續使用相關服務的組織發布電信合作夥伴詳細資訊
  • 2026 年 10 月 5 日： SSPR 註冊活動開始
  • 2026 年 10 月 26 日： Entra ID 品牌設定中的自訂 CSS 定位屬性（positioning properties）全球退役
  • 2026 年 10 月 30 日： 電信合作夥伴組態開放
  • 2026 年 11 月 3 日： 動態群組、AU 與權利管理（entitlement management）中的 MemberOf 規則運算子退役
  • 2026 年 11 月 9 日： SSPR 強制執行——僅接受明確註冊的方法
  • 2027 年 2 月 1 日： Microsoft 代管的 SMS/語音驗證全面退役（無法退出）

在 X 上追蹤 Kevin：https://x.com/kkaminsk，每日取得 Microsoft Entra 更新與分析。