跳轉到主要內容
當一個金鑰外洩、一個約聘人員離場，或一個權杖單純老化時，你 需要替換一個已註冊 MCP 伺服器上的憑證，而不拆除 伺服器記錄、重新撰寫它的防火牆規則，或中斷 已透過閘道連接的代理。那就是輪替的意義： 更新一個現有伺服器上的驗證，而 MCP 閘道 會在它派發的下一次 tools/call 上開始注入新密鑰。 每個伺服器的驗證在靜態時加密並讀取時遮罩，所以 明文權杖永不會往返回到你的主控台、你的代理或 模型。輪替是一個透過工作區主控台的單欄位更新。

​
1. 為何 MCP 密鑰輪替是它自己的動作

一個已註冊的 MCP 伺服器持有三件你不想在一個 憑證變更時失去的事：一個唯一的工作區 name（你的規則 glob 比對的 <server>.<tool> 命名空間）、一個 endpoint，以及它探索到的工具 集。刪除並重新建立伺服器以變更一個權杖會孤立 每一條限定範圍至 <server>.* 的規則，並強制一次全新的探測。 輪替繞開了這一切。你用新的 auth_json PUT 同一筆伺服器 記錄；其他一切——name、規則、探索到的工具——都保持不動。
閘道在派發時注入憑證，只在要進行 上游呼叫時才解密它們。一個輪替後的密鑰會在下一次 連線時生效——OrcaRouter 會在每一次伺服器變更時使每工作區工具快取 失效，所以沒有 TTL 需要等待。

​
2. 一次具體的輪替

假設你註冊了一個名為 github 的 MCP 伺服器並帶有一個 bearer token，而 那個權杖需要更換。先讀取目前的記錄——回應 會遮罩密鑰，所以你永不會處理舊的明文： 
# 從主控台工作階段（UserAuth）設定，而非一個轉送金鑰。
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42 \
  -H "Authorization: Bearer <your console access token>"
然後只用新憑證 PUT 同一筆記錄。在主體中送出 id 與全新的 auth_json；閘道會在它接觸資料庫之前 重新加密它： 
curl -X PUT https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your console access token>" \
  -H "Content-Type: application/json" \
  -d '{
    "id": 42,
    "auth_json": "{\"token\":\"ghp_NEW_token\"}"
  }'
你省略的欄位會保持不動——name、endpoint、auth_mode 與 enabled 全部保留它們已儲存的值。新權杖在下一次 tools/call 上線。
回送遮罩以保留一個密鑰；送出一個真實值以變更它。 如果你 讀取記錄並逐字 PUT 回去，auth_json 中的遮罩預留位置 會被辨識為「保留已儲存的內容」——密鑰不會 被遮罩覆寫。只有一個真正的新 auth_json 才會輪替 憑證。

​
3. 變更驗證模式，不只是密鑰

輪替也涵蓋在驗證方案之間移動一個伺服器。auth_mode 值的 封閉集合是：
無憑證。auth_json 為空。用於公開或 網路信任的 MCP 伺服器。
{ "token": "…" } —— 作為一個 Authorization: Bearer 標頭傳送。
{ "client_id": "…", "client_secret": "…", "token_url": "…" }。如果你 在 JSON 中儲存一個靜態 access_token，閘道會把它作為一個 bearer token 傳送；client-credentials 交換本身尚未執行，所以 一個需要即時交換的伺服器會失敗，直到你提供一個權杖。
{ "username": "…", "password": "…" } —— HTTP basic auth。
在兩個帶憑證的模式之間切換（例如 bearer → basic）需要 在同一個請求中送出一個全新的 auth_json。已儲存的密文 與其原始模式綁定，所以舊密鑰無法在新形狀下被 重新解讀——提供新憑證，否則更新會被拒絕。

​
4. 輪替之後：重新探測

如果舊權杖已被撤銷，一個輪替後的憑證會變更你能觸及哪些 工具。探測該伺服器以確認新 驗證可運作並刷新它的可觸及性 status： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your console access token>"
探測會用新的解密憑證執行一次 MCP 握手並 回報 ok、degraded 或 down。一次驗證失敗會在這裡浮現， 而非作為一個在執行中途令人困惑的工具錯誤。

​
5. 角色與保持遮罩的內容

本頁上的每一個動作都是一個工作區限定的主控台呼叫 （/api/workspace/firewall/mcp_servers，UserAuth）並受角色控管：
動作最低角色
讀取一個伺服器（密鑰遮罩）Member
輪替／更新／註冊Developer+
刪除Developer+
明文永不會被回傳到你的主控台。 讀取會遮罩密鑰並 隱去端點；閘道是唯一會解密一個 憑證的東西，且只在它撥接上游伺服器的那一刻。模型 與你的代理既看不到舊權杖也看不到新權杖。

​
6. 這如何融入

輪替是更廣泛 MCP 信任表面中的一個操作。一旦你的 伺服器已連接並驗證，同一個閘道會在每一次 tools/call 執行之前對照你的防火牆政策評估它、 在其上套用技能隔離，並 治理外向觸及範圍。

連接一個伺服器

註冊一個 MCP 伺服器並探測它的工具。

驗證

為每個伺服器挑選正確的驗證模式。

允許清單 MCP 工具

限定每個伺服器可以公開哪些工具。

Egress 限制

治理工具呼叫可以觸及何處。
關於完整的伺服器生命週期，請見 防火牆：MCP 伺服器， 而關於端到端的強化過程，請見 MCP 信任檢查清單。 輪替也是對抗 MCP 工具下毒與 資料外洩的常設項目：一個你 可以快速更換的憑證，是一個外洩無法久踞的憑證。

​
FAQ

不必。輪替只變更憑證。伺服器保留它的 name， 所以每一條限定範圍至 <server>.* 的規則——以及任何 允許清單——都保持附加。
新密鑰會在下一次派發的 tools/call 上注入。沒有 快取 TTL 需要等待——OrcaRouter 會在每一次伺服器變更時使工作區工具 快取失效。
不行——而那正是重點。讀取會回傳一個遮罩的密鑰；明文 只會由閘道在派發時解密。透過送出一個 新值來輪替，然後探測以確認它運作。