hihi，我是歐娜😺

昨天講 Indirect Prompt Injection 時，

一直在提：

Agent
↓
Email
Website
Database
Tool

但問題來了。

AI 到底要怎麼跟這麼多不同的系統溝通？

難道：

Google Drive 寫一套
GitHub 寫一套
Database 再寫一套
Slack 又寫一套

每接一個服務，

就自己重新設計一次嗎？

這時候就會遇到最近 Agent 世界非常常看到的一個名詞：

MCP（Model Context Protocol）。

MCP 可以先理解成 AI 跟外部工具之間的共同介面

MCP 是一個開放標準，

目的是讓 AI Application 能用比較一致的方式連接外部的資料與工具。

我自己一開始會把它想成：

幫 AI 跟外部世界定義一個共同的溝通方式。

概念大概像：

AI Application
↓
MCP
↓
Google Drive
GitHub
Database
Internal API
File System

這樣 AI Application 不需要每接一個系統，

就重新發明一套完全不同的方式。

先看三個角色

MCP 裡會常看到三個角色：

Host
Client
Server

可以先不用想得太複雜。

Host

Host 就是實際使用 LLM 的應用程式。

例如：

AI IDE
Desktop AI App
自己的 Agent Application

MCP Client

Client 是 Host 裡負責跟 MCP Server 溝通的那一層。

它會去問 Server：

你有哪些能力？

或者：

我要呼叫這個 Tool。

MCP Server

Server 則負責把真正的能力提供出來。

所以概念可以想成：

AI Application（Host）
↓
MCP Client
↓
MCP Server
↓
真正的外部系統

例如：

AI Application
↓
MCP Client
↓
Google Drive MCP Server
↓
Google Drive

Tool、Resource、Prompt 又是什麼？

MCP 裡最常看到的就是：

Tool
Resource
Prompt

Tool

Tool 比較像：

可以真的執行事情的能力。

例如：

searchFiles()
createIssue()
sendMessage()
queryDatabase()

Model 可以決定：

我現在需要呼叫這個 Tool。

Resource

Resource 比較像：

可以提供給 AI 讀取的資料。

例如：

文件
設定檔
資料內容

Prompt

Prompt 則可以提供一些可重複使用的 Prompt Template。

所以 MCP Server 不一定只是：

提供 API。

它可以同時告訴 AI：

我有哪些資料
我有哪些 Tool
我有哪些 Prompt Template

那為什麼 MCP 很方便？

假設以前我要做一個 AI Developer Assistant。

希望它可以：

讀 GitHub Issue
查 Database
搜尋公司文件
建立 Ticket

我可能需要分別研究：

GitHub API
Database Driver
Document API
Ticket API

然後每一個都自己包成 Tool。

MCP 出現之後，

可以變成：

GitHub MCP Server
Database MCP Server
Document MCP Server
Ticket MCP Server

AI Application 用比較一致的方式去連。

所以從開發角度看，

真的很方便。

但……

方便通常就代表新的 Trust Boundary 出現了🤣

MCP Server 其實站在一個非常重要的位置

想像現在架構變成：

LLM
↓
MCP Client
↓
MCP Server
↓
你的資料 / 系統

MCP Server 可能知道：

有哪些 Tool
Tool 可以做到什麼
怎麼連外部 API
怎麼拿資料
需要什麼 Credential

甚至它可能真的擁有：

讀檔案
寫檔案
查 Database
建立 Issue
呼叫 Cloud API

的能力。

所以 MCP Server 不是：

一個無關緊要的小 Connector。

它其實是在：

AI 跟真正系統權限之間。

這也是為什麼 MCP 開始流行之後，

資安問題會很快跟上來。

「AI 可以看到 Tool」跟「AI 可以使用 Tool」差很多

假設一個 MCP Server 提供：

readFile()
writeFile()
deleteFile()

Agent 一連上去，

就可能知道這些 Tool 存在。

如果你的 Agent 只需要：

讀文件。

那其實只需要：

readFile()

但如果 MCP Server 一次把：

writeFile()
deleteFile()

也全部開出去，

Agent 可以做的事情就突然大很多。

這又回到前面一直講的：

Least Privilege（最小權限）。

MCP 只是提供連接方式。

它不會自動替你決定：

哪個 Agent 應該拿哪些權限。

這件事情還是應用程式自己要負責。

MCP 也沒有讓外部內容突然變可信

還記得昨天的 Indirect Prompt Injection 嗎？

MCP Server 可能提供：

readEmail()
readWebsite()
getDocument()

Agent 呼叫之後拿回一段文字。

這段文字最後還是：

外部資料

不是因為：

它是透過 MCP 拿回來的。

就突然變成可信內容🤣

所以：

MCP Tool Result

一樣可能包含：

錯誤資料
惡意內容
Prompt Injection
敏感資訊

MCP 解決的是：

怎麼連。

不是：

連到的東西一定安全。

這兩件事情要分開。

Authentication 跟 Authorization 一樣不能少

如果今天 MCP Server 可以存取公司資料，

當然不能：

任何人連上
↓
都能呼叫所有 Tool

還是需要：

Authentication
→ 你是誰？

Authorization
→ 你能做什麼？

所以開發者還是要正確設計：

誰可以連？
可以使用哪個 Tool？
拿到什麼 Scope？
Tool 裡面還需不需要再次驗證？

不是：

有 OAuth，所以安全問題結束了。

我覺得 MCP 最重要的一個觀念

我一開始看到 MCP，

很容易把它想成：

AI 世界的萬用轉接頭。

這個理解其實沒有離太遠🤣

但從 Security 的角度來看，

每多接一個 MCP Server，

其實就是多了一個：

資料來源
Tool 來源
權限來源
信任邊界

所以問題不只是：

這個 MCP Server 能不能用？

還要問：

我為什麼相信它？

例如：

誰寫的？
從哪裡裝的？
它提供哪些 Tool？
它需要哪些權限？
它可以看到什麼資料？
它會把資料送去哪裡？

這就剛好接到下一篇。

因為現在很多 MCP Server 不是你自己寫的。

而是：

別人寫好，你直接裝。

那問題就來了：

你裝進來的那個 MCP Server，真的可以直接相信嗎？