メインコンテンツへスキップ
ゲートウェイはエージェントとそれが呼び出すすべてのモデルの間に位置します。 それにより、どの SDK が呼び出しを発行したかに関わらず、プロバイダに関わらず、 すべての呼び出し — すべてのプロンプト、すべてのレスポンス、すべてのツール呼び出し、 エージェントがゲートウェイを経由してルーティングするすべてのアウトバウンドリクエスト — を見ることができる唯一のポイントになります。そのチョークポイントが検査と強制の 置き場所です。（見ることができないもの — ゲートウェイを一度も横断しないプロセス内で 完全に実行されるツール — は§4で扱われます。） このページでは、ゲートウェイが見ることができるものとできないもの、検出の仕組み、 そしてギャップを埋める方法を正確に説明します。

​
1. なぜゲートウェイが適切な検査ポイントであるか

ほとんどのセキュリティコントロールはアプリケーションに存在します：ライブラリ ラッパー、エージェントフレームワークフック、プロバイダごとの SDK。それらのコントロールには 致命的な構造的欠陥があります — 2 番目のプロバイダを追加したり、フレームワークを 変更したり、エージェントが新しいスキルを自己インストールしたりするとすぐに壊れます。 ゲートウェイにはそのような継ぎ目はありません。エージェントが発行するすべての呼び出しは、 モデル、プロバイダ、またはツールケイパビリティがどのように到達したかに関わらず、 アップストリームに到達する前に単一のポイントを通過します。これが保証を行える唯一の レイヤーです：もし起きたなら、ゲートウェイはそれを見た。 OrcaRouter はその位置を 2 つの異なる強制パスに使用します：
  • ガードレールはテキストをスクリーニングします — エージェントが送るプロンプトと モデルが返すレスポンス。ガードレールのブロックは HTTP 400 guardrail_blocked を返し、クォータを消費しません。
  • ファイアウォールはアクションを判断します — エージェントが呼び出すツール、 到達する MCP サーバー、および報告するネットワーク宛先。ファイアウォールの deny は inbound サーフェスでは HTTP 400 firewall_blocked を返し、MCP サーフェスでは ツールエラーを返すため、モデルは拒否を見て推論できます。
両方のレイヤーはワークスペースで一度設定され、API キーにアタッチされます。 再デプロイ不要。SDK 変更不要。エージェントは https://api.orcarouter.ai/v1 を 以前と全く同様に呼び出し続けます。

​
2. 4 つの強制サーフェス

ファイアウォールはすべてのツール呼び出しを正確にひとつのサーフェス — ゲートウェイが呼び出しライフサイクル上でそれを見るポイント — に対して評価します。
サーフェスゲートウェイが見るもの
inboundエージェントがリクエストでモデルにアドバタイズするツール — ツール定義。ここでブロックすることでモデルが危険なツールを選択することを防ぎます。
responseモデルがその返信で発行する tool_calls — ディスパッチされる前のモデルが選択したアクション。
mcpファイアウォール MCP ゲートウェイ経由でディスパッチされるか、SDK フック経由で評価される tools/call — ディスパッチの瞬間の呼び出し。
egressツールが報告するアウトバウンドネットワーク宛先（ホスト / IP / CIDR） — SSRF とデータ持ち出しのサーフェス。
ガードレールは上記のサーフェスの上に重なる 2 つのテキストステージを追加します： input（リクエストプロンプトとメッセージ）と output（モデルのレスポンステキスト）。 ひとつのリクエストがすべてを通過することができます。

​
3. 初回使用時の検出

検出はゲートウェイで、初回使用時に行われます — インストール時ではありません。 エージェントが自己インストールしたツール、MCP サーバー、またはスキルは、 その呼び出しが初めてゲートウェイを横切ったときに捕捉されます。これは意図的なものです： ゲートウェイはケイパビリティがどのように到達したかに関わらず、すべてのプロバイダ、 すべてのエージェント、すべての呼び出しを見る唯一のチョークポイントです。 インストール時の検出を待つと、実行時にロードされたケイパビリティを見逃します。
これは、どのルールもそれに名前をつけていなくても、新しいツールがリクエストに 現れた瞬間に Discovered tools ビューに表示されることを意味します。 observe mode をオンにして、マッチするルールがないすべてのツール呼び出しを カバレッジギャップとして記録します — そのビューが実際のトラフィックからの ポリシー作成を駆動します。

​
4. ゲートウェイが見ることができないもの

検査の保証はゲートウェイを横断する呼び出しをカバーします。エージェントが 完全に自身のプロセス内で実行するツール — ローカルファイルを読み取ったり、 ライブラリ関数を呼び出したり、ゲートウェイにメッセージを送ることなく サブプロセスを実行したりするもの — には及びません。 これは設計上の欠陥ではなく、正直な境界です。設計目標は、重要な呼び出し — 現実世界への影響を持つもの — のための監査済みパスをゲートウェイにすることです：
実行場所ゲートウェイは見るか？ギャップを埋める方法
モデル媒介ツール呼び出し（モデルが tool_calls を発行）はい — response サーフェス必要なアクションなし；既に統制されています。
ファイアウォール MCP ゲートウェイ経由の MCP ディスパッチはい — mcp サーフェス必要なアクションなし；既に統制されています。
エージェントがディスパッチ前に POST /api/v1/firewall/evaluate を呼び出すはい — インラインで評価evaluate フック経由で既に統制されています。
ツールがプロセス内で実行され、ゲートウェイに接触しないいいえMCP ディスパッチとネットワーク呼び出しツールを、エージェントプロセスから直接呼び出す代わりにゲートウェイ経由でルーティングします。
今日プロセス内で実行し現実世界への影響を持つツールがある場合、カバレッジへの パスは、ファイアウォール MCP ゲートウェイの背後に MCP サーバーとして登録するか、ディスパッチ前にエージェントループから evaluate フックを呼び出すことです。

​
5. 検査データへのロールゲート

検査サーフェスへのアクセスはワークスペース内でロールスコープされます：
ケイパビリティ最低ロール
ガードレールマッチ、ファイアウォールポリシー、発見されたツールを読み取るメンバー
ファイアウォールの Events & Runs フィードを読み取るDeveloper
ガードレール、ファイアウォールポリシー、ルールを作成または変更するDeveloper
コンプライアンスエクスポート、ファイアウォールゲートウェイスコープキープレーンテキスト、is_firewall_gateway キーフラグAdmin
ファイアウォールゲートウェイスコープトークン（/api/v1/firewall/evaluate と MCP ゲートウェイを呼び出すために使用するキー）の作成には Admin ロールが必要です。 通常の API キーはそれらのルートで 403 を返します。

​
6. 次のステップ

コントロールスタック

完全なリクエストパス — キー、ガードレール、モデル、ファイアウォール、監査 — ひとつの図で。

責任共有

ゲートウェイが保護するものとアプリケーションに残るもの。

エージェントファイアウォール

ポリシーを作成し、サーフェスを設定し、ツール呼び出しを詳細に統制します。
ゲートウェイはそれを横断するすべての呼び出しの単一の検査ポイントです — ポリシーを一度設定すれば、すべてのプロバイダ、すべてのエージェント、 すべてのツール呼び出しがカバーされます。