メインコンテンツへスキップ
登録済み MCP サーバーは、好きなだけツールをアドバタイズします — そしてエージェントは 喜んでそのどれでも呼び出します。安全な姿勢はその逆です：実際に必要なツールの短い リストを決め、まさにそれらを許可し、残りを拒否します。それが許可リストであり、 OrcaRouter では mcp サーフェス上で評価される tool_name_glob ルールから構築 します。 MCP ゲートウェイを越えるすべての tools/call は、 実際のサーバーに到達する前にあなたのファイアウォールポリシー を通ります。したがって許可リストは助言的ではありません — 許可しなかったツールへの 呼び出しは決してディスパッチされません。
ポリシーの編集はコンソールアクションです。/api/workspace/firewall/* ルートは、 リレーの sk-orca-… キーではなく、あなたのセッション／アクセストークンで認証します。 ルールの書き込みには Developer+ ロールが必要です；任意のワークスペースメンバー （Viewer まで）がポリシーと発見されたツールのフィードを読めます。

​
1. なぜセキュアな mcp tools にはデフォルト拒否の許可リストか

拒否リスト — 「危険なツールをブロックする」 — は、サーバーが新しいツールを追加した、 1 つの名前を変えた、あるいは 2 つ目のサーバーを接続した瞬間に失敗します。危険な ツールの集合は限りがありません；あなたが使うつもりだった集合は小さく既知です。 許可リストはデフォルトを反転させ、未知のものを許可するのではなく拒否します：
  • 新しいツールはデフォルトで拒否されます。 接続後に delete_repo ツールを 生やしたサーバーは、それを許可リストに追加するまで呼び出せません。
  • スコープはサーバーごとです。 <server>.<tool> 名前空間により、github.* の 下の残りすべてを拒否しつつ github.create_issue を許可できます。
  • ひとつのチョークポイント。 同じポリシーが、ゲートウェイの背後のバンドル サーバーとすべての BYO サーバーを統制するため、許可リストを読む場所はひとつです。
許可リスト化はobserve モードと自然にペアになります： まずそれをオンにし、実際のトラフィックに発見されたツール フィードを populate させ、それから見えたツールを明示的な許可ルールに昇格させ、 デフォルトを拒否に切り替えます。

​
2. 2 つのピース

許可リストは default_verdict と順序付けられたルールのセットです。

default_verdict: deny

どのルールもマッチしない任意の tools/call に対するポリシーのフォールバック。 それを deny に設定すると、明示的に許可しなかったものはすべてブロックされます。 （allow と audit も受け付けます — audit がデフォルトです。）

allow ルール

ツールごと（またはグロブごと）に 1 ルール。それぞれは tool_name_glob と allow の判定を持ちます。グロブにマッチする tools/call は allow に解決されディスパッチ されます；それ以外はすべて deny デフォルトに落ちます。
グロブは名前空間化されたツール名 — github.create_issue、shell.exec — に対して マッチされます。* は任意のツールにマッチします（控えめに使ってください；* を持つ allow ルールは許可リスト全体を打ち消します）。先頭の <server>. はグロブを 1 つの サーバーにスコープします。

​
3. 具体例 1 つ

github サーバーを接続し、エージェントには読むこととイシューを開くことだけを させたい — 何かを削除したり管理したりは決してさせない。コンソールで Firewall → Policies を開き、ポリシーのデフォルト判定を deny に設定し、 2 つの allow ルールを追加します：
Ordertool_name_globVerdict
1github.create_issueallow
2github.list_issuesallow
それが許可リスト全体です。デフォルトが deny の状態で：
  • github.create_issue → ルール 1 にマッチ → allow、ディスパッチ。
  • github.delete_repo → 何にもマッチしない → デフォルトで deny。
拒否された MCP 呼び出しは、ツールエラー（firewall deny: …）としてモデルに戻って きます — 任意の失敗するツールが返すのと同じ形状です — ため、エージェントはクラッシュ する代わりに適応できます。（inbound サーフェスでは、deny は代わりにエラーコード firewall_blocked を伴う HTTP 400 です。）
ルールは順序付けられており、上から下へ評価されます。広い tool_name_glob: github.* の allow を、特定の deny ルールの上に置かないでください — 最初のマッチが勝ち、ワイルドカードが除外しようとしたまさにそのツールを許可して しまいます。迷ったら、許可リストを狭く保ち、ワイルドカードではなく deny デフォルトに 頼ってください。

​
4. 引数で厳格化する

許可リスト上のツール名でも、不正な引数で呼び出されることがあります。ルールに args_match 句（JSONPath と eq、contains、regex、in、cidr_match のような 演算子）を追加するか、特定の引数形状に対して allow の上に deny ルールを重ねることで さらに絞り込みます — たとえば github.create_issue を許可するが、対象リポジトリが 承認済みリストにないときは deny する。完全な演算子セットについては ファイアウォールルールリファレンスを参照してください。
sanitize は転送前にツール呼び出しの引数をリダクトします — ツールが返すものに 触れることは決してありません。返されたコンテンツをトリミングするには、それは別の制御 です；ツール出力のサニタイズを参照してください。

​
5. 安全にロールアウトする

本番でサーバー全体のデフォルト拒否に切り替えると、忘れていたツールにひっそり依存して いたエージェントを壊すリスクがあります。2 つの設定がそれをデリスクします：
強制判定を audit にダウングレードするポリシーごとのフラグ。あなたの deny デフォルトと deny ルールは、ブロックする代わりに [shadow] would deny … を ログに記録するため、実際に作用する前に許可リストを実トラフィックに対して検証でき ます。詳しくは強制モードを参照して ください。
カバーされていないすべての呼び出しを発見されたツール フィード内のギャップとしてログに記録するワークスペース設定。許可リストを書く前に 実行して、エージェントが正確にどのツールを呼ぶかを学び、それぞれを明示的な allow ルールに昇格させます。
シャドウログがクリーンになったら — 正当な呼び出しが拒否されることはなかったら — shadow_mode をクリアして、許可リストが強制されます。

​
6. 機能することを確認する

強制した後、拒否されたツールが実際に拒絶されることを確認します：
  • ポリシーに対して tools/call をドライラン（Developer+）して、判定とどのルール — またはデフォルト — がそれを生成したかを、実トラフィックを送らずに確認します。 ツール名、サーフェス、サンプル引数を渡すと、エンジンはそれらを評価し、イベントを 記録せずに判定トレースを返します。
  • イベントを監視します。 ブロックされた各呼び出しは、Developer+ がコンソール で読めるファイアウォールイベントを記録します；監査イベント ページがフィードとそのフィールドをカバーします。
各ルールを手書きしたくないですか？ tight 自律性プリセットがあなたのために デフォルト拒否ポリシー（さらに破壊的シェルツールと fetch 形状のツール名への deny ルール）を書き、それからあなたが必要な特定のツールを追加し戻します。各自律性レベルが 何をインストールするかについては 強制モードを参照してください。

​
関連

MCP サーバーの接続

そのツールを許可リスト化できる前にサーバーを登録します。

ファイアウォール：MCP サーバー

ゲートウェイのランタイム挙動と呼び出しごとの判定。

ファイアウォールルールリファレンス

完全なルール DSL — グロブ、args_match、egress、sanitize。

危険なツール呼び出し

許可リストが封じ込めるために作られた脅威。

egress 制限

許可されたツールが到達してよい先を統制します。

ガードレール vs. ファイアウォール

コンテンツポリシーとツールポリシーのどちらに手を伸ばすか。