メインコンテンツへスキップ
キーが漏洩したとき、コントラクターが離任したとき、あるいはトークンが単に古くなった とき、サーバーレコードを取り壊したり、そのファイアウォールルールを書き直したり、 ゲートウェイ経由ですでに接続しているエージェントを中断したりせずに、登録済み MCP サーバーのクレデンシャルを交換する必要があります。それがローテーションです： 既存サーバーの認証を更新すると、MCP ゲートウェイが ディスパッチする次の tools/call から新しいシークレットの注入を開始します。 各サーバーの認証は保存時に暗号化され読み取り時にマスクされるため、平文トークンは あなたのコンソール、エージェント、またはモデルに往復で戻ることは決してありません。 ローテーションはワークスペースコンソールを通した 1 フィールドの更新です。

​
1. なぜ MCP シークレットローテーションが独立したアクションなのか

登録済み MCP サーバーは、クレデンシャルが変わるときに失いたくない 3 つのものを 持ちます：一意のワークスペース name（ルールがグロブする <server>.<tool> 名前空間）、endpoint、そしてその発見されたツールセットです。トークンを変えるために サーバーを削除して再作成すると、<server>.* にスコープされたすべてのルールが孤立し、 新しいプローブを強制されます。 ローテーションはそのすべてを回避します。同じサーバーレコードを新しい auth_json で PUT します。それ以外のすべて — name、ルール、発見されたツール — はそのまま残ります。
ゲートウェイはクレデンシャルをディスパッチ時に注入し、アップストリーム呼び出しを 行うためだけにそれらを復号します。ローテーションされたシークレットは次の接続で 反映されます — OrcaRouter はすべてのサーバー変更でワークスペースごとのツール キャッシュを無効化するため、待つべき TTL はありません。

​
2. 具体的なローテーション 1 つ

bearer トークンで github という名前の MCP サーバーを登録し、そのトークンを ロールする必要があるとします。まず現在のレコードを読みます — レスポンスは シークレットをマスクするため、古い平文を扱うことは決してありません： 
# Configure from the console session (UserAuth), not a relay key.
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 モードを変える

ローテーションはサーバーを認証スキーム間で移動させることもカバーします。auth_mode の値の閉じた集合は：
クレデンシャルなし。auth_json は空です。公開またはネットワーク信頼された MCP サーバーに使います。
{ "token": "…" } — Authorization: Bearer ヘッダーとして送られます。
{ "client_id": "…", "client_secret": "…", "token_url": "…" }。JSON 内に静的な access_token を保存すると、ゲートウェイはそれを bearer トークンとして送ります。 クライアントクレデンシャル交換そのものはまだ実行されないため、ライブの交換を 必要とするサーバーは、トークンを供給するまで失敗します。
{ "username": "…", "password": "…" } — HTTP basic auth。
2 つのクレデンシャル付きモード間（例：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 サーバーを登録し、そのツールをプローブします。

認証

各サーバーに適切な auth モードを選びます。

MCP ツールの許可リスト化

各サーバーが公開してよいツールをスコープします。

egress 制限

ツール呼び出しが到達してよい先を統制します。
完全なサーバーライフサイクルについては ファイアウォール：MCP サーバーを、エンドツーエンドの ハードニングパスについては MCP 信頼チェックリストを参照してください。 ローテーションはまた、MCP ツールポイズニング とデータ持ち出しに対する常設の項目でも あります：速くロールできるクレデンシャルは、漏洩が居座れないクレデンシャルです。

​
FAQ

いいえ。ローテーションはクレデンシャルだけを変えます。サーバーは name を保つ ため、<server>.* にスコープされたすべてのルール — および任意の 許可リスト — はアタッチされたまま です。
新しいシークレットは、次にディスパッチされる tools/call で注入されます。待つべき キャッシュ TTL はありません — OrcaRouter はすべてのサーバー変更でワークスペース ツールキャッシュを無効化します。
いいえ — そしてそれが要点です。読み取りはマスクされたシークレットを返します。 平文はゲートウェイによってディスパッチ時にのみ復号されます。新しい値を送って ローテーションし、それからプローブして機能することを 確認してください。