接入既有系統
MCP 與審批：可以連到那個工具，不等於可以做那個動作
寫給已經在運行 MCP 伺服器或 MCP 閘道，接下來要回答「那一筆退款、那一個帳戶停用、那一次生產環境變更由誰批准」的平台與保安團隊。
GembaOS 是企業 AI Agent 的治理執行平台：以政策判定權限、以綁定參數的單次放行令授權每一個動作、以可追責的簽署鏈記錄人的審批，部署於企業本地機房或私有 VPC。這篇講的是：連線本身已經受管之後，MCP 的工具呼叫與生產系統之間還應該放甚麼。
MCP 閘道決定了甚麼，又留下了甚麼
MCP 閘道決定連線：哪一個用戶端、以甚麼身分、用甚麼憑證、連到哪一個伺服器，以及向這個呼叫方公開哪些工具。這些決定全部發生在「沒有人知道 Agent 實際會要求甚麼」的時候。工具清單先派發，參數後到。
| 問題 | 由閘道決定 | 逐個動作決定 |
|---|---|---|
| 這個 Agent 可不可以連到這個工具 | 是 | — |
| 用哪一個憑證 | 是 | — |
| 這一張訂單、這個金額的退款可不可以做 | 否 | 政策 |
| 由誰負責 | 否 | 簽署鏈 |
| 到寫入那一刻是否仍然成立 | 否 | 主機的現實核對 |
| 會不會執行兩次 | 否 | 單次放行令 |
這不是閘道設計上的缺陷，而是層次不同。閘道管存取；接下來要管的是一個動作的授權。
GembaOS 放在哪裡
敏感的工具呼叫改為送到 GembaOS 的能力閘道，而不是直接送到業務系統。由這裡開始，呼叫要經過架構白皮書所述的四道閘：政策判定、路徑所要求的簽章、一張綁定實際參數的單次放行令，以及主機在寫入前一刻重新讀取現實狀態。
Agent 自己的編排與 MCP 用戶端維持不變。改變的是敏感呼叫落在哪裡，以及事後留下甚麼：一張雜湊串連、可重放的工單，內含核實過的事實、參數、簽章與執行結果。
哪一層承擔哪一種風險
| 風險 | 由哪一層處理 |
|---|---|
| Agent 連到本來不應看見的工具 | 閘道的工具公開範圍與身分規則 |
| 長期有效的憑證留在 Agent 的上下文裡 | GembaOS：憑證留在能力閘道，只在一張放行令之下釋出給一次呼叫 |
| 文件或工具描述裡的指示要求更大的權限 | GembaOS：內容是資料，不是授權；標記為可疑輸入的動作會轉交人手 |
| 事後講不出是誰批准了那次寫入 | GembaOS：審批單上指名者的通行密鑰簽章，代簽時記錄代簽關係 |
| 判斷與寫入之間記錄已經改動 | GembaOS：現實核對、鎖住該記錄、重新讀取上限——見過時的審批 |
| 重試導致寫入兩次 | GembaOS：單次放行令，加上由主機產生的冪等鍵 |
小結
MCP 解決了 Agent 怎樣連到工具，但沒有解決工具做完之後由誰負責，而一份工具清單也回答不了一個關於金額的問題。存取交給閘道，至於會動錢、會停帳戶、會改生產環境的動作，請放在政策判定、指名簽章，以及一張用一次就作廢的放行令後面。
本文回答的問題
GembaOS 會取代我們的 MCP 閘道嗎？
不會。閘道管的是連線：哪一個用戶端可以連到哪一個伺服器、用甚麼憑證、看得見哪些工具。GembaOS 管的是一個被提出的動作：可不可以發生、由誰簽章、以及用一張綁定參數的單次放行令確保只執行一次。大部分部署兩者並存。
呼叫方是 MCP 用戶端時，人手審批怎樣運作？
該工具呼叫會送到能力閘道，而不是直接送到業務系統。政策決定路徑；路徑若保留了人的一步，這個呼叫就變成審批單，由指名的審批人以通行密鑰簽章，放行令依那個人看見的參數簽發。
我們要改動 MCP 伺服器嗎？
伺服器自己的介面維持不變。改的是敏感呼叫送去哪一個端點，以及 Adapter 就該次寫入要聲明甚麼，包括如何防範並發變更。介面與 Adapter 的工作量在架構諮詢階段界定。
工具描述文字會不會令 Agent 取得更大的權限？
不會。權限不來自內容。工具描述、取回的文件、收到的訊息，一律當作資料；一個動作可不可以發生，由模型以外的政策依授權表判定。因此要求更多權限的文字，不會變成更多權限。
資料來源
截至 2026 年 9 月，GembaOS 未取得任何第三方認證；本站的控制對應表為自評，未經審計。GembaOS 處於 Design Partner 階段。 了解 Design Partner 計劃。
最後更新: · GembaOS v0.2