メインコンテンツへスキップ
リモートの MCP サーバーは、エージェントがツールを 呼び出す単なる HTTP エンドポイントです — そしてそのほとんどはトークン、OAuth クライアント、または basic auth の背後にあります。そのサーバーを ファイアウォールの MCP ゲートウェイの背後に登録する とき、あなたは OrcaRouter にクレデンシャルを一度渡し、それがどう認証するかを選び、 ゲートウェイがディスパッチ時にそれを注入します。シークレットは保存時に暗号化され、 モデルやあなたのエージェントコードに渡ることは決してありません。 このページはサーバー登録の認証側をカバーします：4 つの auth_mode 形状と、あなたの クレデンシャルに何が起こるかです。接続が確立された後、ゲートウェイが各 tools/call に対して行うすべて — 呼び出しごとのポリシー、名前空間化、SSRF 保護 — については MCP ゲートウェイリファレンスを参照してください。

​
1. なぜゲートウェイで認証するのか

ゲートウェイがなければ、MCP サーバーと話すすべてのエージェントは、そのサーバーの トークンの独自コピーを持ち、設定とプロンプトに散在します。代わりにサーバーを OrcaRouter 経由でルーティングすれば、クレデンシャルは正確にひとつの場所に存在します：
  • サーバーごとにひとつの保存シークレット。 クレデンシャルをワークスペース レコードに一度登録します。エージェントは OrcaRouter キーでゲートウェイに接続します — それらはアップストリームサーバーのトークンを決して見ません。
  • 保存時に暗号化、読み取り時にマスク。 クレデンシャルは保存されるときに暗号化 されます。コンソールや SDK 経由でサーバーを読み戻すたびに、シークレットはマスク されて戻ってきます — それを平文で返す API はありません。
  • ディスパッチ時に注入。 ゲートウェイは、tools/call を実際のサーバーに転送する 瞬間にだけクレデンシャルを復号し、それをそのアウトバウンドリクエストに添付します。 モデルやクライアントにエコーされることは決してありません。
読み戻せないクレデンシャルは、ギャップではなく機能です。読み取りが常にマスクされる ため、漏洩したコンソールセッションや SDK トークンは、あなたの MCP サーバー シークレットを持ち出すことはできません — それらを再ポイントするか、ローテーション することしかできません。

​
2. auth_mode を選ぶ

すべてのサーバー登録は auth_mode を持ちます。それは 4 つの値の閉じた集合で、 auth_json で供給するクレデンシャルの形状を決定します：
サーバーはオープン（またはネットワークによってゲートウェイを信頼）です。 auth_json を空のままにします。これは auth_mode を設定しないときのデフォルト です。
ホストされた MCP サーバーで最も一般的なケース。1 つのトークンを供給します。 ゲートウェイは各呼び出しで bearer クレデンシャルとしてそれを送ります。
{ "token": "ghp_…" }
OAuth 保護されたサーバー向け。すでに発行した access_token を供給します。 ゲートウェイは bearer とまったく同様に bearer クレデンシャルとしてそれを送り ます。自動的なクライアントクレデンシャル交換（client_id/client_secret を 新しいトークンと交換すること）はまだ利用できません — access_token のない oauth 登録は拒否されます。
{ "access_token": "…" }
HTTP basic auth。
{ "username": "…", "password": "…" }
auth_json は、auth_mode が none 以外のときは常に必須です。空のクレデンシャル で bearer/oauth/basic サーバーを登録することは拒否されます — ゲートウェイは 中途半端に設定された接続を永続化しません。

​
3. セキュアな MCP サーバーの登録 — 例 1 つ

MCP サーバーの登録はコンソールアクションです：/api/workspace/firewall/mcp_servers に対してあなたのセッション／アクセストークンの下で実行され、サーバーの書き込みには Developer+ ロールが必要です。（これは /v1/* モデル呼び出しに使う sk-orca-… リレーキーとは異なります — そのキーはワークスペース設定を管理しません。） ファイアウォールコンソールから、またはセッショントークンを直接使って、bearer 認証 サーバーを登録します： 
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
name はワークスペースごとに一意で（重複は HTTP 409 を返します）、. を含む ことはできません — その文字はツールを <server>.<tool> として名前空間化します。 入力時、OrcaRouter は auth_json を暗号化し暗号文のみを保存します。サーバーを 読み戻すと、マスクされた形が得られます。
保存されたシークレットを変更しないままにするには、更新時にマスクされた値をそのまま 返します — 実際にローテーションしたいときだけ、本物の auth_json を送ります。 ローテーションフローについては クレデンシャルローテーションを参照して ください。

​
4. 接続が機能することを証明する

ゲートウェイが保存したクレデンシャルで実際にサーバーに到達できるまで、認証は完了 していません。それをプローブします： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"
ゲートウェイは復号されたクレデンシャルを使ってエンドポイントに接続し、サーバーの ツールを一覧し、到達可能性 status を記録します：
status意味
ok到達かつ認証済み；ツールが発見された。
degraded到達可能だが完全には健全でない。
down接続または認証できなかった。
登録直後の down の結果は、ほとんどの場合、不正なクレデンシャルまたは誤った auth_mode を意味します — auth_json を修正して再プローブします。プローブは Developer+ アクションです。バンドルされたインプロセスサーバーはエンドポイントを 持たず、プローブ不可です。
無効化されたサーバーはクリーンなオフスイッチです：そのツールはゲートウェイから消え、 そのクレデンシャルは決して復号されません。認証を整理する間サーバーを無効化し、 プローブが ok で戻ってきたら再有効化します。

​
5. エージェントからサーバーを読む

あなたのエージェントはクレデンシャルを読みません。SDK プロキシがランタイム レジストリを必要とするとき、ファイアウォールゲートウェイスコープのキー — 専用の キーで、リレーキーでもセッションでもありません — を使って GET /api/v1/firewall/mcp_servers を呼び出します。そのパスは有効なサーバーのみを 提供し、ゲートウェイは依然としてクレデンシャル注入を端から端まで所有します。 エージェントを統合された MCP エンドポイントに接続することは、 ゲートウェイリファレンスで カバーされています。

​
6. 次のステップ

最初のサーバーの接続

空のワークスペースから稼働中のツールまで、完全な登録ウォークスルー。

クレデンシャルのローテーション

接続を落とさずに、漏洩または期限切れのシークレットを交換します。

MCP ツールの許可リスト化

サーバーのどのツールをエージェントが実際に呼び出してよいかを決めます。

egress を制限する

サーバーのツールがネットワーク上で到達してよい先を制約します。
この背後にある概念 — ゲートウェイがどうリクエストパス上に位置し、なぜクレデンシャル がモデルに触れないか — については OrcaRouter の検査方法と AI エージェントのセキュリティを参照して ください。これが閉じる脅威については MCP ツールポイズニングと データ持ち出しを参照してください。