這起事件真正值得警惕之處，不是一段惡意文字「騙過」模型，而是企業把讀取內容、存取機密與執行操作三種能力交給同一個 AI Agent，卻仍沿用「使用者看得到、核准過，就算安全」的傳統假設。當人類與模型接收到的內容不同，原本的審查流程便可能只剩形式。
事件背景：攻擊者藏起來的不是程式碼
來源事實：Cyber Security News 報導，Manifold Security 發現 Microsoft 官方 Azure DevOps MCP Server 的間接提示注入風險。Azure DevOps 的 Pull Request（PR）描述支援 Markdown，也容許 HTML 註解；這類註解不會呈現在網頁畫面上，API 卻會原樣傳回。當開發者要求 AI 程式助理審查 PR，模型便可能讀到人類看不見的指令。原始報導：https://cybersecuritynews.com/azure-devops-mcp-flaw/
Manifold 的第一方研究進一步說明，其概念驗證由只有單一專案貢獻權限的攻擊者建立 PR，再誘導審查者的 Agent 啟動另一個專案的 pipeline、讀取機密 wiki，最後把內容貼回攻擊者可見的 PR。研究團隊表示，這條攻擊鏈已在 Copilot CLI 與 Claude Code 上驗證：https://www.manifold.security/blog/azure-devops-mcp-server-vulnerability
運作機制：被借走的是審查者的權限
這是典型的「混淆代理人」（confused deputy）問題。攻擊者沒有破解帳號，也沒有直接取得 Payments 等其他專案的權限；真正執行動作的是使用受害者身分驗證資訊的 Agent。若資深審查者擁有比 PR 作者更廣的跨專案權限，惡意文字便可能藉由 Agent 借用這段權限落差。
攻擊鏈可拆成四個信任轉換：攻擊者可寫入的 PR 描述，被系統當成待分析資料；資料進入模型上下文後，被誤認為指令；模型再把指令轉成合法 MCP 工具呼叫；最後，wiki 內容透過 PR 留言成為攻擊者可讀的輸出。每一個 API 呼叫都可能通過既有授權，危險來自它們被串接後的目的，而非單一動作本身。
為何現在值得注意
來源事實：Microsoft 官方儲存庫說明，Azure DevOps MCP Server 是讓 Agent 存取專案、儲存庫、pipeline、wiki 與工作項目的薄層介面，並由語言模型負責較複雜的推理。官方文件也顯示，本機版本預設載入所有工具領域，可用 -d 參數縮小範圍：https://github.com/microsoft/azure-devops-mcp
合理推論：這種設計的商業價值與安全風險來自同一件事——Agent 不只回答問題，還能直接完成工作。工具越完整、核准步驟越少，自動化效益越高；但一旦外部內容成功改寫任務目標，跨專案權限與可寫入的回傳通道也會同步擴大損害。
既有防線為何漏掉這一扇門
Microsoft 早已在 2026 年 3 月合併 PR #1062，為 wiki 頁面與 pipeline build log 加入「spotlighting」：以隨機分隔符標記外部內容，並提示模型不要把其中的文字當成指令。該變更及測試範圍可由官方 PR 核對：https://github.com/microsoft/azure-devops-mcp/pull/1062
問題在於，PR 描述的回傳路徑沒有套用相同處理。這顯示內容安全不是「MCP Server 有沒有防護」的二元問題，而是每一個可讀取外部文字的工具、欄位與回傳分支是否都被納入。Microsoft 自己也將 spotlighting 定義為機率性防禦，並列出分隔、資料標記與編碼等模式；它能提高攻擊門檻，不能取代權限隔離：https://www.microsoft.com/en-us/msrc/blog/2025/07/how-microsoft-defends-against-indirect-prompt-injection-attacks
實際影響與容易忽略的限制
來源事實：獨立媒體 The Hacker News 查證，概念驗證使用本機 v2.7.0，且需同時具備幾項條件：攻擊者能寫入 PR 文字、受害者把該內容交給 Agent、受害者權限較廣，以及 Agent 能在沒有逐項確認的情況下執行工具。截至其 7 月 21 日查證，未見公開資料證明攻擊已在 Manifold 測試以外遭實際利用，也沒有已修正版本或 CVE：https://thehackernews.com/2026/07/microsoft-azure-devops-mcp-flaw-lets.html
因此，這不是「任何人貼一段註解就能入侵所有 Azure DevOps」；其風險高度取決於權限範圍、已啟用工具與核准政策。研究也只直接測試本機、PAT 驗證的伺服器，不能把遠端版本受影響視為已完成驗證。反過來說，僅以「攻擊者本來就有專案寫入權」淡化事件也不恰當，因為攻擊目的正是跨越原有專案邊界。
對台灣軟體團隊的意義
作者觀點：台灣企業若把 Azure DevOps、AI code review 與 CI/CD 串在一起，最該改變的不是提示詞，而是權限架構。程式審查 Agent 不需要讀取營運機密 wiki，就不應載入 wiki 工具；不需要部署，就不應具備啟動 pipeline 的能力；需要跨專案查詢時，也應使用專用、短效且可稽核的身分，而不是完整繼承資深工程師權限。
人工核准仍有價值，但核准畫面必須呈現 Agent 即將呼叫的工具、目標專案及資料流向，不能只顯示模型整理後的摘要。否則攻擊指令若同時要求「不要告訴使用者」，人類看到的結論與實際執行軌跡可能完全不同。
後續觀察指標
- Microsoft 是否為 PR 描述、留言、工作項目等所有攻擊者可控欄位一致套用外部內容隔離，並發布修正版或安全公告。
- 本機與遠端 MCP Server 是否具有相同回傳路徑，以及官方是否明確說明兩者受影響範圍。
- 企業稽核紀錄能否偵測「審查 PR 後立即跨專案啟動 pipeline、讀取 wiki、再貼出留言」這類異常序列。
- Agent 平台是否支援依任務配置工具白名單、專案邊界、資料外傳限制與高風險操作逐次核准。
這起事件的核心教訓是：官方連接器可以是可信軟體，經由它取得的內容卻未必可信。當 AI 開始代表人操作企業系統，安全邊界必須從「它有沒有權限」進一步轉向「這項任務為何需要這個權限，以及資料最後流向哪裡」。