メインコンテンツへスキップ
MCP エージェントは、リーチを持つエージェントです。それが接続するすべての Model Context Protocol サーバーは、誰もレビューしていない新たなツール、クレデンシャル、 ネットワーク宛先のセットです — そしてエージェントは実行途中で新しいものを取り込めます。 このレシピは、広がりがちな MCP セットアップを、ホスト型ゲートウェイ上で統制された ものに変える 4 つの動きを示します：単一の監査済み MCP ゲートウェイ、スキルの quarantine、egress の拒否、そして暗号化されたサーバー認証。 そのすべてを、あなたのワークスペースに対してコンソール（または REST API）から 設定します。あなたのエージェントは、以前と全く同様に MCP を話し続けます。

​
1. なぜ MCP エージェントをセキュアにするのか

エージェントを 5 つの MCP サーバーへ直接向けると、5 つの信頼境界、5 つの クレデンシャルストア、そしてゼロの共有監査証跡を持つことになります。顧客レコードを 読む tools/call と、シェルコマンドを実行するものは、モデルには同一に見え、 コミュニティサーバーは初めてロードされるときに shell.exec と外部ネットワークスコープを ひっそり要求し得ます。 修正は、OrcaRouter をすべての呼び出しが横切る唯一のチョークポイントにすることです。 MCP エージェントのトラフィックをエンドツーエンドでセキュアにするには、すべての MCP ディスパッチをファイアウォールの MCP ゲートウェイ経由で ルーティングし、すべての tools/call が実サーバーに到達する前にポリシー評価される ようにします — スキルはリスクスコアリングされ、egress は統制され、クレデンシャルは 保存時に暗号化されます。
これはレシピです — 既存の機能を 1 つの具体的な強化パスにつなぎ合わせます。完全な リファレンスについては、ファイアウォール、 MCP サーバー、 スキルへのリンクをたどってください。

​
2. Secure Agents ベースラインから始める

あつらえのものを作成する前に、姿勢を設定します。コンソールで Firewall → Posture を開き、balanced 自律性レベルを 適用します（Developer ロール）。ひとつのトランザクションで、最も破壊的なアクションを deny しながらツール呼び出しを audit し、PII を flag します — 広く強制する前に観察し、 ワンクリックの取り消しを持ちます。 Events と Runs フィードが正しく見えたら、 tight に移ります：デフォルト deny、破壊的シェル deny、SSRF 形の egress deny、 加えて PII Shield と Secrets Blocker ガードレールの強制。その単一のスイッチが、 このレシピが構築する土台です。
ワークスペース全体を切り替えずにランプアップしたいですか？ 下記のルールを 1 つの 名前付きポリシーに作成し、そのシャドウモードをオンにします — 確信が持てるまで、 評価とログは行うが、すべての強制判定を audit に格下げします（理由には [shadow] would … が前置されます）。 強制モードを参照。

​
3. すべての tools/call を 1 つの MCP ゲートウェイ経由でルーティングする

各 MCP サーバーを一度登録します；ゲートウェイは単一の接続の下にそれらのツールを集約し （<server>.<tool> で名前空間化）、すべての tools/call をファイアウォールエンジン 経由で実行します。 コンソール（または REST API、Developer+）からサーバーを登録します： 
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
  }'
それから、専用のファイアウォールゲートウェイスコープのキーを使って、あなたの MCP クライアントを — アップストリームサーバーではなく — ゲートウェイに向けます： 
https://api.orcarouter.ai/api/v1/firewall/mcp
これで github.create_issue と shell.exec が 1 つの接続の下に並んで現れ、各 ディスパッチは実行前に評価されます。ブロックされた呼び出しは、トランスポートの クラッシュではなくツールエラー（firewall deny: …）としてモデルに返ってくるため、 エージェントは適応できます。
通常のリレーキーは、ゲートウェイルート /api/v1/firewall/mcp で 403 を受け取り ます。MCP 接続のために専用のゲートウェイトークン（is_firewall_gateway）を発行 してください；そのゲートウェイキーの平文を読むには Admin+ が必要です。
サーバーのツールに対してルールを書けるようになる前に、それをプローブしてツール名と スキーマを発見します： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-session-token>"

​
4. エージェントが取り込むスキルを quarantine する

MCP ゲートウェイは呼び出しを統制します；スキルガバナンスはエージェントがロードする ケイパビリティを統制します。インストール可能なすべてのスキル、BYO MCP サーバー、 あるいはプラグインは、すべてのルール判定の上に乗るリスクバンドと強制モードへスキャン されます：
モード実行時の効果
allowルール判定が決定します；スキルは何も追加しません。
quarantinedeny 未満のものは pending_approval のために保留されます。
blockスキルのツールは強制的に deny されます。
MCP エージェントにとっての要点：誰も承認していないケイパビリティはフリーパスを 得ない。エージェントが何かを自己インストールし、そのツールが初めてゲートウェイを 横切るとき、ファイアウォールはそれを自動検出し、たとえスキャンがクリーンでも 人間がレビューするまで quarantine します。信頼するサーバーは事前承認し、残りは レビューキューに着地させます。
あなたのエージェントが実際に何をインストールするかを学ぶ間は balanced/observe を オンに保ち、それから信頼するスキルを allow にプロモートし、ロングテールは quarantine のままにします。スキルを参照。

​
5. SSRF 形の egress を deny する

侵害された、あるいは混乱した MCP ツールがクラウドメタデータやイントラネットホストへ 到達するのは、典型的な持ち出しの道です。2 つのレイヤーがそれをカバーします。 第一に、ゲートウェイは、登録時と各ディスパッチホップで、すべてのリモート MCP エンドポイントとその解決済みダイヤル IP を SSRF ポリシーに対して検証します — イントラネット範囲とクラウドメタデータアドレスは拒否され、DNS リバインディングを 打ち破るために再チェックされます。これは組み込みです；あなたが設定する必要は ありません。 第二に、tight 自律性レベルは、fetch 形のツール名 — http_fetch、 web_search、fetch_url、request、およびそれらの <server>.* 名前空間化された 形 — を deny する SSRF egress プリセットを出荷します。つまり、仕事全体が 「この URL を取りに行く」というツールは、ダイヤルする前に止められます。 ツールが宛先別に到達してよい場所を統制するには、host/CIDR deny リストを持つ独自の egress ルールを作成します — それがアウトバウンドリーチを固定するためのサーフェス です： 
// firewall rule, egress stage — deny outbound to an internal range.
// egress_json is a JSON *string*: {"deny":[…],"allow":[…]} of hosts/CIDRs.
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\",\"169.254.169.254\"]}"
}
CIDR egress ルールを出荷するプリセットはありません — SSRF プリセットは宛先ではなく ツール名にマッチします。宛先レベルの制御が必要なときは、host/CIDR deny リストを 自分で作成してください。 egress リストと 持ち出しを止めるを参照。

​
6. サーバークレデンシャルを暗号化したまま保つ

すべての MCP サーバーの auth_json は保存時に暗号化され、読み取り時にマスクされます； ゲートウェイはディスパッチ時にクレデンシャルを注入するため、モデルやクライアントには 決して届きません。サポートされる auth_mode 値：
{ "token": "…" } — 静的なベアラートークン、Authorization: Bearer として 送信されます。
{ "client_id": "…", "client_secret": "…", "token_url": "…" } — client-credentials OAuth；ゲートウェイがトークンを取得しリフレッシュします。
{ "username": "…", "password": "…" } — HTTP Basic 認証。
"" — 認証なしのサーバー。デフォルト。
読み取り時にシークレットはマスクされます；保存値を保つには、更新時にマスクをそのまま エコーバックします。最後のプローブ からのサーバーの status（ok / degraded / down）は、依存する前に到達可能か どうかを教えてくれます。

​
7. リクエストにコンテンツガードレールを追加する

ファイアウォールはアクションを統制します；MCP エージェントを通って動くテキストも スクリーニングされるように、ガードレールと組み合わせます。 Secrets Blocker プリセットは、モデル — あるいはどのツール — も見る前に、リクエスト内のクレデンシャルを 捕捉し、PII Shield は入ってくる 途中で識別子をマスクします。どちらも tight 自律性レベルでオンになるか、guardrail_id 経由で名前付きガードレールをエージェントのリレーキーにアタッチします。
ファイアウォールの sanitize 判定はツール呼び出しの引数をリダクトするのであり、 ツールが返すコンテンツは決してリダクトしません。Secrets Blocker ガードレールで リクエストからシークレットを取り除き、ファイアウォールルールでエージェントが発する 引数をサニタイズします。両者はフローの異なる半分をカバーします。

​
8. 検証して監視する

信頼する前にポリシーが期待どおりに動くことを確認し、それからフィードに目を配ります：

ツール呼び出しをテストする

あなたのポリシーに対してサンプルの tools/call をドライランし、判定、マッチした ルール、理由を見ます — 何もディスパッチされず、何もログされません。

Discovered tools

ワークスペースが見たすべてのツール、covered または gap とフラグ — 実 MCP トラフィックからまっすぐルールを作成します。

Events & Runs

すべてのディスパッチ、その判定、そしてそれが当たったサーフェスを、エージェント run ごとにロールアップ。

異常フィード

学習されたベースラインに対するレート／コストのスパイク、リトライループ、そして 新規のツールパス。

​
9. 次に進む先

MCP ツールポイズニング

quarantine と MCP ゲートウェイの背後にある脅威モデル。

過剰なエージェンシー

自律的なツール使用にとってデフォルト deny と HITL がなぜ重要か。

自律エージェントのレシピ

高自律性エージェントをエンドツーエンドで強化します。

持ち出しを止める

アウトバウンドの egress を深くロックダウンします。