Securing MCP: A Control Plane for Agent Tool Execution
devblogs.microsoft.com · 2026-04-22
Model Context Protocol（MCP）近年來快速成為 AI Agent 與外部工具溝通的標準介面，讓 Agent 可以存取資料庫、呼叫 API、操作檔案系統與第三方服務。但這個協議有一個根本性的設計缺口：MCP 只定義了「如何呼叫工具」，卻完全沒有定義「誰有權利在什麼情況下呼叫哪些工具」。換句話說，MCP 標準化了執行介面，卻沒有任何治理機制。
問題在哪裡？MCP 的安全盲點
當 MCP client 連接到一個 tool server，它收到的是工具定義（tool definitions）——包含工具名稱、描述與參數 schema。模型選定工具後，client 就直接序列化請求並送出執行。整個流程中，沒有任何環節去檢查：這個 Agent 有沒有資格呼叫這個工具？這組參數是否符合合規要求？這次呼叫是否在預期的業務邏輯範圍內？
對小型 demo 來說，這種「隱性信任」無傷大雅。但當 MCP tool server 連接的是真實的生產系統——有存取控制、合規要求、敏感資料——這個設計缺口就變成了真實的攻擊面。
微軟整理了 OWASP MCP Top 10 所定義的主要風險類別，並且已有實際的 CVE 案例佐證：
- CVE-2025-49596：MCP Inspector 的未認證遠端程式碼執行（Unauthenticated RCE）
- CVE-2025-66416：Python SDK 的 DNS rebinding 漏洞
攻擊向量主要有四類：
- Tool Poisoning（工具投毒，MCP03:2025）：惡意 tool server 在工具描述中嵌入隱藏指令，讓 Agent 在不知情的情況下洩漏資料或抑制其他合法工具。
- Prompt Injection：工具回應中夾帶對抗性指令，改變 Agent 後續的推理行為，且這些被污染的輸出會在多輪工具呼叫中持續傳播。
- Supply Chain Attacks：Agent 動態發現工具時，typosquatting（相似名稱偽冒）或被入侵的工具定義會混入可用工具清單，與合法工具享有同等信任。
- Cascading Failures：Agent 對出錯的 MCP server 不斷重試，在缺乏 circuit breaker 保護的情況下，可能觸發連鎖故障並拖垮下游服務。
紅隊測試的量化數字
微軟針對 OWASP Agentic Top 10 設計了一套紅隊基準測試，共 60 個提示（45 個對抗性、15 個合法請求）。測試結果顯示：僅靠 prompt 層面的安全指令，政策違規率高達 26.67%——也就是每四次對抗性攻擊就有超過一次成功。這個數字說明了一個核心問題：「叫模型自己注意安全」不能作為安全邊界，指令遵從性（instruction-following）無法取代確定性的執行層把關。
解法：Agent Governance Toolkit（AGT）
微軟開源了 Agent Governance Toolkit（AGT），目前處於 Public Preview 階段。它的定位是一個 runtime 治理層，坐落於 MCP client 和 tool server 之間，在每次工具呼叫真正執行前進行政策評估。
工具定義掃描（Tool Definition Scanning）
在工具定義進入模型的 context 之前，AGT 會掃描其中是否含有隱藏指令、typosquatting 或對抗性模式。被污染的定義在觸及模型之前就被攔截或標記。
每次呼叫的政策執行（Per-Call Policy Enforcement）
政策以宣告式規則表達，支援 YAML、OPA/Rego 或 Cedar 語法。每次工具呼叫前都進行確定性評估。微軟內部 microbenchmark 顯示，典型規則集的評估開銷在 sub-millisecond（毫秒以下）等級，在大多數部署場景中相對於 LLM round trip 可忽略不計。
身份與信任（Identity and Trust）
每個 Agent 獲得加密身份，採用 Ed25519 加上量子安全的 ML-DSA-65 雙重簽章，建構在 SPIFFE 相容的身份框架上。信任分數採 0–1000 的數值尺度，違規會導致分數衰減，持續合規行為則逐漸回升。
執行閘控與可觀測性
採用四層特權環（four-tier privilege ring）模型，強制執行最小權限原則，並設有 kill switch 機制可立即終止不合規的 Agent。所有工具呼叫嘗試、政策決策和執行結果都記錄在追加式（append-only）、哈希鏈接（hash-chained）的稽核日誌中，支援事後的重放除錯（replay debugging）。
覆蓋範圍與框架支援
AGT 對 OWASP MCP Top 10 的覆蓋情況：10 項風險中 7 項完整覆蓋、3 項部分覆蓋（Token 管理、意圖流程顛覆、Shadow MCP Server）。框架整合方面，AGT 提供 20+ 個主流框架的 adapter，包括 LangChain、AutoGen、CrewAI、Semantic Kernel、OpenAI Agents SDK 和 Google ADK。SDK 語言支援涵蓋 Python、TypeScript、.NET、Rust 和 Go。
已知限制與路線圖
AGT 目前以單次工具呼叫為粒度進行治理，尚未具備跨呼叫序列的關聯分析能力——每次呼叫個別合法、但組合起來形成惡意工作流的情況目前還無法偵測。這個能力列在路線圖中。微軟也在探索「意圖宣告（intent declaration）」機制：讓 Agent 在執行前先宣告行動計畫，以便進行前置驗證。
工程師可以學到什麼
這篇文章提出了一個重要的安全設計原則：協議層的標準化不等於治理層的到位。MCP 讓 Agent 可以輕鬆接入工具，但這種便利性本身就是攻擊面的擴張。任何在生產環境中部署 MCP 的工程師，都應該認真考慮在 client 和 server 之間加入明確的政策執行層。AGT 提供了一個可以直接採用的開源方案，而其設計思路——宣告式政策、密碼學身份、確定性評估——也值得在任何 Agent 安全架構設計中作為參考。
直接透過上游的 security patch 生整套 exploit 出來
blog.gslin.org · 2026-04-22
這篇文章討論的是一個令人警醒的資安研究議題：當一個漏洞的 security patch 被公開發布之後，攻擊者可以直接從 patch 的差異內容，借助 LLM 的幫助，自動化地還原出完整可用的 exploit。這不是理論上的可能性，而是已經有實際概念驗證（PoC）的技術現實。
案例背景：iTerm2 的任意程式碼執行漏洞
文章的引發點是一個針對 iTerm2（macOS 上廣受開發者使用的終端機模擬器）的安全漏洞研究。這個漏洞的危險程度出乎意料：光是執行 cat readme.txt 這樣的日常指令，就可能導致任意程式碼執行（Arbitrary Code Execution，ACE）。原因在於 iTerm2 會解析終端機輸出中的特定跳脫序列（escape sequences），而惡意構造的 readme.txt 檔案可以利用這個行為執行攻擊者控制的程式碼。
這個漏洞的原始分析來自「MAD Bugs」系列的研究報告，標題為「'cat readme.txt' is not safe in iTerm2」，詳細記錄了漏洞的技術機制。
核心議題：從 patch 到 exploit 的自動化流水線
文章的真正重點不是這個特定漏洞本身，而是一個更廣泛的安全研究方法論問題：安全 patch 一旦公開，研究人員（或攻擊者）可以用 LLM 輔助，從 patch 的 diff 反向工程出完整的 exploit。
具體的研究產出包括：
- prompts.md：記錄了引導 LLM 從 patch 內容推導漏洞根因與利用方式的完整提示詞流程
- genpoc2.py：由 LLM 輔助生成的概念驗證 exploit 腳本，功能上等同於手工撰寫的早期版本 genpoc.py
這個流程的意義在於：它大幅降低了漏洞利用的門檻。過去，從一個 patch 還原出可用的 exploit 需要資深的逆向工程師花費數天甚至數週。現在，即使沒有深度資安背景的人，也可以借助 LLM 在短時間內完成類似的工作。
對資安生態的影響：patch 發布視窗的壓縮
文章指出一個重要的現實：許多資安團隊在 patch 公開後就立刻啟動這個流程，以評估自己的系統面臨的風險等級，進而決定是否需要緊急推送更新。這是一個防禦性的應用。
但這個工具的存在同時也意味著：從 patch 發布到可用 exploit 出現的時間視窗正在急遽縮短。傳統的「patch Tuesday」思維——即在下次例行維護週期推送修補——面臨嚴峻挑戰，因為攻擊者可能在數小時內就完成 exploit 開發。
iTerm2 的案例尤其值得關注：文章提到 iTerm2 團隊在漏洞 patch 公開後，並沒有立即推送更新給用戶。這種做法在 LLM 輔助 exploit 生成的時代，等同於讓用戶在已知漏洞面前裸奔。
技術層面：為什麼 LLM 能做到這件事
從 patch 到 exploit 的推導過程涉及幾個步驟，而 LLM 在每個步驟都能提供實質協助：
- patch 差異分析：LLM 能閱讀 git diff 並解釋修改的語義——哪裡加了邊界檢查、哪裡修正了緩衝區大小、哪裡改變了輸入驗證邏輯
- 漏洞根因推導：從「修了什麼」反推「原本哪裡錯了」，以及錯誤的觸發條件
- exploit 構造：根據漏洞類型（緩衝區溢位、格式字串漏洞、跳脫序列解析錯誤等）生成對應的 payload 和 PoC 程式碼
- 迭代調試：LLM 可以根據錯誤訊息或測試結果持續修正 exploit 邏輯
工程師可以學到什麼
這篇文章對軟體開發者和資安工程師有幾個直接的啟示：
- patch 發布即紅色警報：任何公開的安全修補，都應視為「exploit 即將到來」的信號。負責任的修補策略是先推送修補給用戶，而不是等等看。
- 終端機模擬器的安全面：iTerm2 的案例提醒我們，開發工具本身也是攻擊面。應持續關注所使用工具的安全公告並保持更新。
- LLM 作為攻防雙向工具：防守方可以用同樣的方法在 patch 公開後快速評估風險；攻擊方也可以。這個工具的存在本身要求我們重新審視 patch 管理的時效性。
- 對「security by obscurity」說不：如果 patch 已經公開，漏洞細節事實上也跟著公開了——只是需要一點推導時間。依賴「攻擊者不知道怎麼利用」作為保護層，在 LLM 時代已經更加脆弱。
Apple fixes bug that cops used to extract deleted chat messages from iPhones
techcrunch.com · 2026-04-22
Apple 於 2026 年 4 月 22 日（週三）發布了 iPhone 和 iPad 的軟體更新，修補了一個被執法機構用來提取已刪除訊息的安全漏洞。這個漏洞的核心問題令人意外地技術性：通知（notifications）的內容被非預期地快取在裝置上長達一個月，即使原始訊息已被刪除。
漏洞機制：訊息刪了，通知快取沒刪
問題的根源在於 iOS 處理通知的方式。當訊息抵達時，iOS 會在通知資料庫中儲存通知內容（包含訊息文字）以便顯示。正常情況下，當訊息被刪除後，對應的通知記錄也應該清除。但這個 bug 導致「標記為刪除的通知，可能出乎意料地被保留在裝置上」（Apple 官方安全公告用語）。
更關鍵的是，這份快取資料存在於 iOS 的通知資料庫中，而不是在訊息應用程式（如 Signal）的儲存空間內。這意味著即使 Signal 的應用程式資料已經完整清除，通知資料庫裡的副本依然存在，且可以透過數位鑑識工具提取。根據 404 Media 的報導，訊息快取保留時間可長達 一個月。
FBI 的實際利用案例
這個漏洞最初由獨立媒體 404 Media 於 2026 年 4 月初揭露。根據該報導，FBI 已實際利用數位鑑識工具，從某人的 iPhone 上提取了已刪除的 Signal 訊息。具體手法是：FBI 透過工具讀取了 iOS 通知資料庫，找到了 Signal 訊息顯示在通知時留下的快取副本——即便這些訊息在 Signal 內部已被自動刪除計時器清除。
Signal 的「閱後即焚」功能（disappearing messages）設計目的就是在訊息被刪除後無法被任何人讀取，包括設備持有者。但 iOS 通知快取的存在繞過了這個保護，讓訊息內容透過作業系統層面的旁路（side channel）留存下來。
Signal 的反應與 Apple 的修補策略
消息公開後，Signal 主席 Meredith Whittaker 公開表示 Signal 方面已要求 Apple 處理這個問題，並指出：「已刪除訊息的通知，不應該被保留在任何作業系統的通知資料庫中。」
Apple 在此次更新中選擇了 backport 策略：修補不只針對最新版 iOS，也同步回移至執行較舊版 iOS 18 的裝置。這個決策表明 Apple 認為這個問題的嚴重性足以讓舊版用戶也需要緊急保護。至於通知內容為何一開始就被記錄到資料庫，Apple 並未公開說明。從修補行為來看，這顯然是一個非預期的 bug，而非設計上的功能。
更廣泛的影響：端對端加密的作業系統信任邊界
這個案例揭示了端對端加密（E2EE）應用程式面臨的一個根本性挑戰：應用程式層的加密安全，可能被作業系統層面的 side channel 所破解。
Signal 的加密實現在應用程式層面是可靠的，但通知系統屬於 iOS 系統層，Signal 對其快取行為的控制能力有限。即使 Signal 的加密金鑰無從取得，訊息的明文內容也可能透過通知快取、背景同步、Spotlight 索引等多個系統層面的機制留存。
對於高風險使用者（記者的線人、維權人士、任何可能面臨設備被查扣的人），這個案例說明：「閱後即焚」功能的安全性取決於整個系統堆疊（system stack）的配合，而不只是應用程式本身。
工程師可以學到什麼
這個案例對應用程式開發者有幾個重要啟示：
- 通知內容敏感性管理：任何處理敏感資料的應用程式，都應考慮通知顯示的內容範圍。iOS 提供了
UNNotificationContent的隱私設定，可以讓通知在鎖定螢幕上顯示為「您有一則新訊息」而非訊息全文。Signal 本身也有「顯示通知」設定，但系統層快取行為超出了應用程式的控制範圍。 - 數位鑑識工具的能力邊界：Cellebrite、GrayKey 等數位鑑識工具不只能讀取應用程式資料，更能深入 iOS 系統資料庫。開發者在進行威脅建模時，應將作業系統層的 side channel 納入考慮。
- 系統更新的重要性：這個 bug 存在於 iOS 系統層，應用程式開發者無法透過應用程式更新修復。確保用戶及時更新作業系統，是安全敏感應用程式的重要課題。
- 安全保證的邊界聲明：在設計「閱後即焚」等敏感功能時，應明確向用戶說明安全保證的前提條件，包括作業系統信任這個環節。
來源：developer.microsoft.com, blog.gslin.org, techcrunch.com