事件背景：問題不在 PR 本身，而在 AI 讀到的版本
資安媒體 Latest Hacking News 報導，Manifold Security 發現 Microsoft 官方 Azure DevOps MCP Server 存在間接提示注入風險：攻擊者可把指令藏在 Pull Request（PR）描述中的 HTML 註解。Azure DevOps 網頁介面不會顯示這段內容，但 API 仍會原樣回傳，AI 審查代理因而可能讀到人類審查者看不見的指令。原始報導：https://latesthackingnews.com/2026/07/26/azure-devops-mcp-flaw-defenses/
這裡必須先釐清：已公開證實的是「PR 描述內的隱藏 HTML 註解」，不等同一般討論串中的留言。Manifold 的第一方研究說明，攻擊者需要先取得某個專案的貢獻者權限、建立惡意 PR，再等待權限較高的使用者叫 AI 代理審查。研究團隊稱已用 Copilot CLI 與 Claude Code驗證概念性攻擊，並向 Microsoft Security Response Center 通報；其揭露頁面表示案件已獲確認及分流處理。技術揭露：https://www.manifold.security/blog/azure-devops-mcp-server-vulnerability
運作機制：一條合法權限組成的攻擊鏈
這不是傳統的權限繞過。MCP Server 把 Azure DevOps 的 PR、Wiki、Pipeline 與工作項目包裝成模型可呼叫的工具；代理則以使用者身分執行。攻擊鏈的關鍵，是把「外部作者提供的資料」誤當成「應服從的指令」。
- 攻擊者在有權寫入的 PR 描述中埋入隱藏指令。
- 受害者要求代理審查 PR，代理透過 MCP 取得包含隱藏文字的描述。
- 模型若服從該文字，便可使用受害者已獲授權的其他工具。
- Manifold 的概念驗證依序啟動另一專案的 Pipeline、讀取機密 Wiki，再把內容貼回攻擊者看得到的 PR。
來源事實是上述工具呼叫鏈已在研究環境重現；合理推論則是，同類路徑也可能涉及原始碼、工作項目或其他代理可讀資料，實際範圍仍取決於受害者權限與啟用工具；目前公開資料不足以證明已有真實環境遭大規模利用。
為何現在值得注意：AI 把身分授權變成可編排能力
Microsoft 官方儲存庫將 Azure DevOps MCP 定位為讓代理直接操作開發平台的薄層工具介面，並列出 PR、Pipeline、Wiki 等多種讀寫能力；本機版若未指定 Domain，預設會載入全部 Domain。官方同時正把使用者導向公開預覽的遠端 MCP Server。這代表風險不只來自「模型會不會答錯」，而是模型能否把多個正常 API 呼叫串成錯誤的業務流程。官方儲存庫：https://github.com/microsoft/azure-devops-mcp
Manifold 指出的程式缺口也有官方程式碼紀錄可交叉驗證。Microsoft 在 2026 年 3 月合併 PR #1062，對 Wiki 內容與建置紀錄加入「Spotlighting」：以隨機分隔標記包住不可信內容，協助模型區分資料與指令；該變更列出的適用工具未包含取得 PR 描述的工具。紀錄：https://github.com/microsoft/azure-devops-mcp/pull/1062
Spotlighting 並非絕對防線。Microsoft Research 的研究顯示，它能在實驗條件下降低間接提示注入成功率，但本質仍是改善模型辨識來源的防禦層，而非權限隔離：https://www.microsoft.com/en-us/research/publication/defending-against-indirect-prompt-injection-attacks-with-spotlighting/?lang=zh-cn
實際影響與修補空窗
受影響程度由三項條件共同決定：代理是否讀取外部可控 PR、憑證是否跨專案有效，以及是否能執行讀取機密、啟動 Pipeline 或對外回寫等動作。只做摘要且沒有其他工具的代理，衝擊遠低於可自主連續呼叫工具、又持有組織級權限的代理。
7 月 26 日的原始報導稱當時尚無 CVE，亦未見修補發布；這是該媒體在發稿時點的狀態，不應延伸解讀為 Microsoft 從未處理，部署者仍須核對自己使用的本機套件或遠端服務版本。尤其官方文件指出，遠端與本機版可能採用不同版本及驗證方式：遠端版使用 Microsoft Entra ID，本機版則可使用 PAT 或 Azure CLI，因此不能用同一份設定清單概括所有環境。
容易忽略的限制：人工確認不是萬靈丹
「有人按下開始」不等於每一步都有人工把關。Manifold 的 PoC 本身就是由人啟動審查，之後代理仍可連續行動；真正有效的是在高風險或跨專案操作前，讓使用者看見具體工具、目標與資料流向並再次確認。反過來說，即使輸入已加上分隔標記，只要代理仍同時擁有廣泛讀取權、寫入管道與高度自主性，殘餘風險依然存在。
Microsoft 的遠端 MCP 文件已提供可縮小攻擊面的控制：以 X-MCP-Toolsets 或 X-MCP-Tools 限定工具，並用 X-MCP-Readonly 關閉寫入能力；官方亦說明遠端服務只能存取登入身分原本獲授權的資料。這驗證了漏洞不會憑空創造權限，卻也凸顯過度授權會直接放大影響。官方文件：https://learn.microsoft.com/en-us/azure/devops/mcp-server/remote-mcp-server-troubleshooting?view=azure-devops
對台灣團隊的意義
作者觀點是，企業不應再把 AI 程式碼審查視為單純的 IDE 外掛。只要它連上 DevOps、票務、雲端或內部知識庫，就已成為持有員工身分、可跨系統執行工作的服務帳號。台灣企業常以專案、客戶或產品線切分 Azure DevOps；若審查者可跨區存取，而代理沿用同一身分，原有專案邊界就可能被一段外部文字借道穿越。
現階段可採取的務實措施，是把 PR 描述、留言、建置紀錄與 Wiki 一律標記為不可信輸入；審查代理只開啟 Repos 所需的唯讀工具；以專案限定、短效身分取代廣泛 PAT；跨專案讀取、Pipeline 執行及對外回寫必須另行核准；並記錄完整工具呼叫序列，針對「審 PR 後突然讀 Wiki、啟動無關建置、回貼大量內容」建立告警。
後續觀察指標
- Microsoft 是否在取得 PR 的工具上全面套用 Spotlighting或更強的來源標記。
- 本機套件與遠端 MCP Server 各自何時更新，以及是否公布 CVE或安全公告。
- 企業是否能把代理權限縮到單一專案、唯讀與最少工具，而非沿用開發者全部權限。
- 稽核系統能否辨識跨專案工具鏈與異常資料回寫，而不只看單次 API 呼叫是否合法。
這起事件真正的警訊，不是 HTML 註解有多高明，而是人類看到的介面、API 回傳的資料與代理理解的指令，已成為三個不同的安全邊界。修掉單一工具固然重要；更長期的工作，是讓任何外部內容都無法單憑文字，支配一個權限比其作者更高的代理。