上一篇我們把 Agent 拆成模型、工具、記憶、設定檔與自主迴圈，但當工具越接越多，就碰到一個工程問題：不同的 AI 應用，能不能用一種共同語言去連這些東西？

假設今天要做一個 AI 助理，希望它能讀本機檔案、查 Git 儲存庫、搜尋公司文件甚至直接開啟工單，沒有共同協定的時候，每接一個服務，都得重新處理 API、認證、資料格式、工具描述和錯誤回應，服務一多整合程式會變成一團各說各話的轉接程式。

MCP（Model Context Protocol）想解決的就是這件事，它替 AI 應用和外部工具、資料來源之間訂了一套共同的溝通方式，讓不同能力的工具可以用一致的方式被呼叫。

依照 MCP 官方架構文件，它專注在 Context Exchange，最常見的比喻是 USB：USB 統一了連接介面，接上各種工具，如滑鼠、硬碟和網路卡；MCP 也是類似的概念，檔案系統、GitHub、資料庫和付款服務都可以透過這個共同協定接進 AI 應用。

圖片來源：Medium Blog

對人來說，這讓 AI 整合外部工具變得方便很多，但從安全的角度來看，每多接一個工具，就等於多開了一扇需要防守的門。

MCP 的三種角色：Host、Client、Server

MCP 採用 Client-Host-Server 架構：

使用生活化的比喻的話，可以這樣理解：

• Host：手機本身或手機裡的 APP
• Client：手機裡負責和某個藍牙裝置溝通的連線模組
• Server：耳機、手錶、汽車音響這些外部裝置

Host：管理整體流程的 AI 應用

Host 是使用者實際接觸的 AI 應用，例如 Claude Desktop、Codex、Cursor 或其他支援 MCP 的聊天工具與 IDE，它持有 LLM Session，負責整合多個 MCP Client，決定哪些 Server 可以被使用，像是使用者同意、權限控制跟 Context 組合，通常是 Host 在處理。

Client：Host 與 Server 的專用連線

Host 會替每個 MCP Server 開一個 Client，由 Client 維護連線、能力協商跟訊息路由，這個一對一的設計有助於隔離 Server，但能不能真的形成安全邊界，還是要看 Host 有沒有把不同 Server 的內容和權限隨便混在一起，如果 Host 把不同 Server 回傳的內容全部混進同一份 Context，或讓某個 Server 的內容影響另一個 Server 的工具選擇，那隔離效果就會大打折扣。

Server：提供資料與動作的地方

Server 負責把服務包裝成 MCP 可以使用的形式，像是 Notion、Google Drive、Slack、GitHub、檔案系統、API 或資料庫等，並向 Client 宣告自己能提供什麼功能，它可以是本機 Process，也可以是遠端服務，但這裡要注意一件事情，本機不代表絕對可信，遠端也不代表一定危險，如果本機 Server 拿到過大的檔案權限，讀取了和任務不相關的敏感資訊並把內容送進 AI 應用中，還是可能造成資訊洩漏，所以真正該看的是來源、執行權限、認證機制以及操作範圍。

MCP 的組成

官方架構把 MCP 分成兩層：

• 資料層（Data Layer）：以 JSON-RPC 為基礎，處理版本與能力探索、Tools、Resources、Prompts 與通知。
• 傳輸層（Transport Layer）：負責實際通訊、訊息框架與授權相關機制。

常見的傳輸方式有兩種：

• stdio：Host 啟動本機 Server Process，再透過標準輸入輸出溝通。
• Streamable HTTP：Client 用 HTTP 跟遠端 Server 溝通，Server 可以搭配 SSE 傳送串流與通知。

同樣是接一個 Server，這兩條線要確認的問題完全不同，stdio 的邊界在作業系統，該確認的是 Host 用什麼命令、用誰的權限把 Server 跑起來，以及那個 Process 能讀寫哪些目錄、拿得到哪些環境變數；Streamable HTTP 的邊界則在認證與網路位置，除了 Server 本身的權限，還會牽涉 OAuth、Token Audience、TLS，以及 SSRF、DNS Rebinding 跟服務是不是暴露在不該暴露的網路位置。

Tools、Resources、Prompts：Server 最重要的三種 Primitive

Tools：模型提出要執行的動作

Tool 通常會包含名稱、描述與 Input Schema，Client 可以透過 tools/list 知道有哪些 Tool，再用 tools/call 呼叫，官方規格把 Tool 視為 Model-controlled，也就是模型可以根據 Context 自己決定要不要使用某個 Tool，但「模型決定要用」和「系統真的允許它執行」必須是兩件事情，例如模型認為現在需要呼叫 delete_file，不代表 Executor 就可以直接照做，執行之前還是要確認要刪哪個檔案、目前是哪個使用者、這個使用者有沒有權限。

Resources：提供模型閱讀的資料也能影響安全

Resource 可以是檔案內容、資料庫紀錄、API 回應或 Schema，雖然它看起來只是唯讀的 Context，但只要內容會進到模型裡，就可能帶來敏感資料洩漏或間接 Prompt Injection 等風險。

除了內容本身，Server 也必須確認目前這個身分有沒有權限讀取指定 Resource URI，並避免 Path Traversal、IDOR，以及錯誤訊息洩漏過多內部資訊。

Prompts：由 Server 提供的重複使用模板

Prompt 是 Server 提供的可重複使用模板，它可以把常見操作整理成固定流程，讓不同 Client 用一致的方式取得或使用這些內容，這樣做雖然方便，但也代表指令來源不一定只存在於 Host 本地，第三方 Server 提供的 Prompt 不能直接把它當成高優先級指令，要保留原本的來源與信任層級。

MCP 的信任邊界

把整個資料流攤開來看，MCP 至少有以下幾個地方需要做信任判斷：

1. 使用者 -> Host：使用者的要求和核准是不是夠明確？
2. Host 或模型 -> Client：模型選擇工具之後，有沒有再經過政策和權限檢查？
3. Client -> Server：Server 的身分、版本、傳輸方式和授權機制能不能信？
4. Server -> 系統：Server 拿的是什麼 Credential，又能操作哪些資料和服務？
5. Server -> Host / Model Context：Server 回傳的 Tool Description、Resource、Prompt 和 Tool Result 會不會影響模型後續判斷、工具選擇，甚至觸發下一步動作？

每新增一個 Server，就多一個風險

MCP Server 可能由官方、第三方社群、內部團隊甚至是某個人維護的專案，而 Server 本身底下通常還會再依賴其他套件、容器或 API，導入 MCP 時要管理的不只有模型版本，還包括：

• Server 從哪裡來、誰在維護，目前還有沒有持續更新。
• 使用的套件、容器、命令和遠端 Endpoint 是不是固定版本。
• Tools、Resources、Prompts 的清單有沒有變動，Description 是否被修改。
• Server 需要哪些檔案、網路、OAuth 權限和 Scope。
• 出問題時，怎麼更新、撤銷、處理事件，以及 Rotation Credential。

OWASP LLM04:2026 Supply Chain 也把 MCP Server 和 Tool Registry 這類 Agentic Supply Chain 風險列入討論，並對應到 Agentic Top 10 裡的 ASI04 Agentic Supply Chain Vulnerabilities。

認證只回答「你是誰」，有 Token 不代表每次操作都被授權

遠端 MCP 可以透過標準授權流程保護敏感資源和操作，官方 Authorization 指南 建議依 Tool 或 Capability 拆分 Scope，並在 Resource Server 端檢查每個 Route 或 Tool 需要哪些權限。

但 OAuth 成功只代表某個 Client 通過身份驗證拿到 Token，不代表接下來每一次 Tool Call 都符合使用者權限與意圖，實作上還是要注意幾件事：

• Token 綁定正確 Audience，不能直接 Pass-through 給其他服務。
• 依 Tool 與動作使用最小 Scope，不要一次要求 files:*、db:* 或 admin:*。
• 每次呼叫都重新驗證使用者、Tenant、資源與參數。
• 高風險操作要顯示實際動作並重新核准。
• Credential 留在 Host 或受控 Broker，不要暴露給模型與生成出來的程式碼。

Authentication、Authorization 與 User Intent 是三件不同的事：你是誰、你能做什麼，以及你這次是不是真的要做這件事。

MCP 安全盤點表

要導入或測試一個 MCP Server 時，可以先回答下面這些問題：

來源與生命週期

• Server 從哪裡安裝？有沒有固定版本、Commit 或 Digest？
• 誰能更新？Tools 或 Description 改變時會不會重新審查？
• 移除 Server 時，Credential、設定與持久資料有沒有一併撤銷？

執行環境

• 本機 Server 的啟動命令是什麼，會用誰的權限執行？
• 它能讀寫哪些目錄、存取哪些環境變數與網路目的地？
• 遠端 Server 有沒有用 TLS 與認證？
• Token 的 Audience 是不是綁定這個 Server？

能力與資料

• 暴露了哪些 Tools、Resources 與 Prompts，其中哪些 Tool 會產生外部或不可逆的副作用？
• Resource 與 Tool Result 有沒有可能包含不可信指令或敏感資料？

授權與觀察

• 每次 Tool Call 是不是依真實使用者情境授權？
• 確認畫面有沒有顯示完整的工具來源、參數與副作用？
• 能力清單變更、呼叫、核准、Credential Scope 與結果有沒有被記錄下來？

這篇的小總結

MCP 讓 AI 應用能用一致的方式發現 Tools、取得 Resources、載入 Prompts，並跟本機或遠端 Server 溝通，它降低了整合成本，也讓外部功能更容易接進 Agent，但工具接得越多，要注意的風險也隨之增加，Server 從哪裡來、拿到什麼權限、可以碰哪些資料、回傳內容怎麼進入模型，以及每一次操作到底是誰批准的，這些都會變成新的安全問題。

下一篇就繼續看看 MCP 的攻擊還有什麼，了解 Tool Poisoning、Rug Pull、Shadowing 和 Credential Theft 這些風險是怎麼發生的。