譯者 | 核子可樂

審校 | 重樓

每種新協(xié)議都會(huì)帶來相應(yīng)的復(fù)雜性，因此若無必要、勿增新協(xié)議。但模型上下文協(xié)議（MCP）無疑很有必要。

ChatGPT等AI工具已然掀起一波智能體應(yīng)用浪潮，這些由大模型驅(qū)動(dòng)的智能體擅長(zhǎng)摘要、內(nèi)容創(chuàng)作與圖像處理，但也存在一些根本性的局限：

• 無法訪問實(shí)時(shí)數(shù)據(jù)；
• 無法訪問私有數(shù)據(jù)；
• 無法使用工具。

作為一種通用協(xié)議，MCP能夠?qū)⒅悄荏w應(yīng)用與現(xiàn)實(shí)世界的數(shù)據(jù)和工具連通，成功解決上述局限。但既然我們已經(jīng)擁有一眾安全且高性能的API，那為什么還要引入新的協(xié)議？

答案并不復(fù)雜，雖然各類強(qiáng)大的API能夠接入智能體應(yīng)用，但由于自身種類繁多、身份驗(yàn)證機(jī)制又各不相同，意味著每次集成都存在大量定制化成分。開發(fā)者必須逐一閱讀文檔、構(gòu)建流程才能接入API。

WSO2

這種靜態(tài)集成模型雖然成熟，但與智能體應(yīng)用的動(dòng)態(tài)特性并不匹配。MCP定義了清晰的客戶端-服務(wù)器角色、標(biāo)準(zhǔn)協(xié)議格式和生命周期，本質(zhì)上成為大模型與外部系統(tǒng)間的通用連接器，因此不少從業(yè)者將MCP視為API領(lǐng)域的USB端口。

MCP工作原理

MCP定義了三大核心角色——主機(jī)、客戶端與服務(wù)器：

• 主機(jī)：管理客戶端生命周期，并具備強(qiáng)制安全保障的智能體應(yīng)用。
• 客戶端：主機(jī)內(nèi)的輕量級(jí)連接器，用于同MCP服務(wù)器建立一對(duì)一會(huì)話。
• 服務(wù)器：將MCP客戶端連接至本地或遠(yuǎn)程數(shù)據(jù)源及工具的程序。

WSO2

各角色提供相應(yīng)的功能。MCP服務(wù)器負(fù)責(zé)公開資源（如日歷事件等上下文數(shù)據(jù)）、提示詞（用于引導(dǎo)用戶輸入以改進(jìn)大模型輸出的結(jié)構(gòu)化模板）及工具（可執(zhí)行函數(shù)）。MCP客戶端則接入MCP服務(wù)器以請(qǐng)求數(shù)據(jù)、操作工具并編排智能體。

MCP使用JSON-RPG（一種輕量級(jí)結(jié)構(gòu)化協(xié)議）以處理請(qǐng)求及響應(yīng)，并定義了兩種用于客戶端-服務(wù)器通信的標(biāo)準(zhǔn)傳輸機(jī)制：標(biāo)準(zhǔn)輸入輸出（STDIO）及可流式傳輸?shù)?/span>HTTP。

保護(hù)本地MCP服務(wù)器

當(dāng)MCP服務(wù)器運(yùn)行在本地時(shí)，應(yīng)使用STDIO傳輸。實(shí)際上，這意味著智能體應(yīng)用將MCP服務(wù)器作為子進(jìn)程啟動(dòng)，并通過其標(biāo)準(zhǔn)輸入輸出流進(jìn)行通信。由于此通信完全在本地系統(tǒng)內(nèi)進(jìn)行，因此本質(zhì)上符合安全原理且MCP身份驗(yàn)證規(guī)范無需借助額外安全措施。

WSO2

然而，當(dāng)MCP服務(wù)器與后端API通信（大多通過互聯(lián)網(wǎng)）時(shí)，安全性要求成為首要任務(wù)、并超出了MCP身份驗(yàn)證機(jī)制的范疇。盡管如此，這里仍不需要引入新機(jī)制：現(xiàn)有API安全實(shí)踐已經(jīng)足以提供保障，常見方法包括：

• 長(zhǎng)效令牌：有效期為數(shù)天或數(shù)月的API密鑰及令牌，通過帶外通道獲取并在MCP服務(wù)器中配置。
• 短效令牌：短效信息的有效期在一小時(shí)以內(nèi)，無法手動(dòng)設(shè)置。相反，MCP服務(wù)器必須在運(yùn)行時(shí)動(dòng)態(tài)請(qǐng)求并獲得用戶批準(zhǔn)。典型例子包括OAuth2訪問令牌及JWT。

保護(hù)遠(yuǎn)程MCP服務(wù)器

MCP客戶端通過向其端點(diǎn)URL發(fā)起請(qǐng)求，通過HTTP接入遠(yuǎn)程MCP服務(wù)器。根據(jù)MCP身份驗(yàn)證規(guī)范的規(guī)定，此端點(diǎn)必須受到OAuth 2.1保護(hù)，并要求客戶端提供有效訪問令牌。

WSO2

MCP身份驗(yàn)證規(guī)范概述了令牌的獲取流程，旨在支持動(dòng)態(tài)智能體集成。具體交互包括以下步驟：

WSO2

服務(wù)器元數(shù)據(jù)發(fā)現(xiàn)

在為MCP服務(wù)器提供URL配置參數(shù)之后，客戶端會(huì)移除所有路徑組件并附加/well-known/oauth-authorization-server路徑以構(gòu)建服務(wù)器元數(shù)據(jù)端點(diǎn)。之后，客戶端從此端點(diǎn)處檢索JSON格式的服務(wù)器元數(shù)據(jù)文檔。端點(diǎn)及文檔都必須符合OAuth 2.0授權(quán)服務(wù)器元數(shù)據(jù)規(guī)范，且此元數(shù)據(jù)可幫助客戶端在后續(xù)步驟中發(fā)現(xiàn)以下所需信息：

• 注冊(cè)端點(diǎn)；
• 授權(quán)與令牌端點(diǎn)；
• 支持的授權(quán)類型與范圍。

從MCP服務(wù)器URL獲取服務(wù)器元數(shù)據(jù)端點(diǎn)的初衷，是讓客戶端使用單一配置參數(shù)進(jìn)行操作。但這樣的設(shè)計(jì)會(huì)令授權(quán)與資源服務(wù)器角色緊密耦合，限制了現(xiàn)有OAuth 2.0基礎(chǔ)設(shè)施與專用身份解決方案的使用。為了解決這個(gè)問題，即將發(fā)布的MCP身份驗(yàn)證規(guī)范將轉(zhuǎn)而采用OAuth 2.0受保護(hù)資源元數(shù)據(jù)規(guī)范。

客戶端注冊(cè)

根據(jù)從服務(wù)器元數(shù)據(jù)文檔中檢索到的信息，客戶端應(yīng)用向客戶端注冊(cè)端點(diǎn)發(fā)送注冊(cè)請(qǐng)求。MCP身份驗(yàn)證規(guī)范采用OAuth 2.0動(dòng)態(tài)客戶端注冊(cè)（DCR）協(xié)議將客戶端注冊(cè)為OAuth 2.1客戶端。在DCR響應(yīng)中，客戶端應(yīng)用會(huì)收到一個(gè)client_id；對(duì)于機(jī)密客戶端，還會(huì)收到一個(gè)client_secret。這兩項(xiàng)參數(shù)將在下一步操作中用到。

盡管DCR得到廣泛采用，但人們對(duì)于開放注冊(cè)的評(píng)判并不一致，而且該規(guī)范本身允許使用OAuth 2.0保護(hù)注冊(cè)端點(diǎn)。同樣，為了支持單參數(shù)配置，MCP身份驗(yàn)證規(guī)范建議采用開放注冊(cè)，未來如何發(fā)展仍有待觀察。

訪問令牌檢索

在此階段，客戶端已經(jīng)做好了請(qǐng)求訪問令牌的所有準(zhǔn)備。根據(jù)用例，客戶端將使用以下OAuth 2.1授權(quán)類型之一：

• 客戶端憑證：若客戶端應(yīng)用直接訪問MCP服務(wù)器，則使用客戶端憑證授權(quán)，其中包含注冊(cè)期間獲得的client_id與client_secret，以及從服務(wù)器元數(shù)據(jù)中發(fā)現(xiàn)的令牌端點(diǎn)及范圍。
• 授權(quán)碼：若客戶端代表最終用戶訪問MCP服務(wù)器，則使用授權(quán)碼授權(quán)。此流程需要注冊(cè)時(shí)獲取的client_id與client_secret，以及從服務(wù)器元數(shù)據(jù)中獲取的授權(quán)端點(diǎn)、令牌端點(diǎn)及范圍。此外，根據(jù)OAuth 2.1的要求，客戶端必須使用碼交換證明密鑰（PKCE）以進(jìn)一步增強(qiáng)安全性。

WSO2

若一切順利，客戶端應(yīng)用將獲得有效訪問令牌，并可向MCP服務(wù)器URL發(fā)起連接請(qǐng)求，并通過Authorizatio nHTTP標(biāo)頭傳遞令牌。之后，MCP服務(wù)器將驗(yàn)證令牌，在確認(rèn)有效后建立連接。

總體而言，整個(gè)安全流程與基于OAuth的典型API安全流程保持一致，唯一區(qū)別只有從MCP服務(wù)器URL獲取服務(wù)器元數(shù)據(jù)URL的初始步驟。

原文標(biāo)題：Why MCP matters – and how to secure it，作者：Sagara Gunathunga