メインコンテンツへスキップ
モデルリレーの外側からエージェントファイアウォールにツール呼び出しを通すには — 独自のエージェントループが evaluate フックを呼ぶ、または MCP クライアントが MCP ゲートウェイに接続する — 通常の sk-orca-… リレーキーではなく、専用の ファイアウォールゲートウェイスコープのキーで認証します。通常のキーはトークン 認証されるファイアウォールゲートウェイルートで 403 を受け取ります（承認コールバックが 唯一の例外です — それはトークンゲートではなく HMAC 署名付きです）。 このページはファイアウォールゲートウェイ API キーとは何か、どう発行するか、そして なぜスコープが Admin+ にゲートされているかをカバーします。エンジン自体については、 ファイアウォールの概要と ファイアウォールの詳細なリファレンスを参照してください。

​
1. ファイアウォールゲートウェイ API キーとは

ワークスペース内のすべてのトークン（API キー）は is_firewall_gateway フラグを 運びます。それが true のとき、キーはファイアウォールゲートウェイサーフェスに到達 できます：
ルート何をするか
POST /api/v1/firewall/evaluate1 つのツール呼び出しに対するディスパッチ前の判定。
POST /api/v1/firewall/evaluate_planマルチステッププランの実行前チェック。
ANY /api/v1/firewall/mcp統合された MCP ゲートウェイエンドポイント。
GET /api/v1/firewall/mcp_serversワークスペースの登録済み MCP サーバーを列挙（復号化されたアップストリーム認証を返す）。
GET /api/v1/firewall/approvals/:id保留された呼び出しの承認状態をポーリング。
is_firewall_gateway = false（デフォルト）のキーは通常のリレーキーです — /v1/* モデルトラフィックを提供し、firewall_policy_id 経由でポリシーをアタッチしていれば、 そのツール呼び出しはインラインで統制されます。しかし上記のゲートウェイルートを 呼び出すことはできません。
2 つの異なるキー、2 つの異なる仕事。 リレーキー（firewall_policy_id がアタッチ された）はエージェントがモデルと話すために使うものです — ファイアウォールがその ツール呼び出しを自動的に統制します。ファイアウォールゲートウェイキーは、エージェント ランタイムがファイアウォールに直接判定を尋ねたり、MCP tools/call をゲートウェイ 経由でプロキシしたりするために使うものです。ほとんどのワークスペースは、evaluate フックまたは MCP ゲートウェイを採用したときにのみゲートウェイキーを必要とします。

​
2. なぜ通常のキーが 403 を受け取るか

ゲートウェイスコープは 2 つのシークレットに敏感なケイパビリティをアンロックするため、 通常のキーから意図的に壁で隔てられています：
  • /evaluate は呼び出し元が供給する request_id を受け入れます。それは ファイアウォールイベントと承認レコードに流れます。任意のモデルキーが監査イベントを 偽造したりポリシー結果をサイレントに探ったりできれば、証跡を損ないます。
  • /mcp_servers は復号化されたアップストリーム認証情報を返します。SDK のプロキシが 登録済みの MCP サーバーにディスパッチできるようにします。 それは認証情報の読み取りであり、モデル呼び出しではありません。
このため、ハンドラは提示されたトークンの is_firewall_gateway フラグをチェックし、 それが欠落しているときに HTTP 403 を返します： 
{
  "success": false,
  "message": "token lacks firewall_gateway scope — mint a dedicated gateway token"
}
高トラフィックのリレーキーをゲートウェイキーとして再利用したり、ゲートウェイキーを リレートラフィックに再利用したりしないでください。アクションプレーンのキーを分離して 保ち、そのブラスト半径とローテーションがモデルキーから独立するようにします。

​
3. 発行する — Admin+ にロールゲート

is_firewall_gateway = true の設定にはワークスペース Admin 以上が必要です。 Developer は通常のキーを作成・編集できますが、ゲートウェイスコープのものを発行 できません — フラグはシークレット管理の関心事なので、通常のトークン書き込みロールの 上に位置します。 キーはコンソールの、ワークスペース API キーのもとで設定します。ゲートウェイキーを 発行するには：
1

Admin として API キーを開く

ワークスペース Admin（以上）としてサインインし、コンソールの API キーページを 開きます。
2

ゲートウェイスコープでキーを作成する

新しいキーを作成し、その firewall gateway スコープ（is_firewall_gateway）を 有効にします。Developer ロールのセッションはスコープが効力を持つのを見ません — サーバーは非管理者に対してフラグを false に保ちます。
3

キーを一度コピーする

作成時にキーの完全な値をコピーします。その後、コンソールは表示時にそれを マスクし、ゲートウェイキーの平文を読み返すこと自体が Admin+ です — 非管理者は「自分のキーを取得」レスポンスからゲートウェイ行を省略されます。
フラグを下げることは上げることより寛容です：is_firewall_gateway をクリアする こと（ゲートウェイキーを通常のキーに降格）は、キーを編集できる任意のロールに開放されて います。それを true に上げることのみが Admin+ です。

​
ロールゲート概観

アクションロール
通常のキーを作成/編集Developer+
is_firewall_gateway = true を設定Admin+
ゲートウェイキーの平文を読み返すAdmin+
is_firewall_gateway をクリア（降格）任意のキー編集者

​
4. 具体例 1 つ

エージェントループを実行していて、ツール呼び出しをディスパッチする前にチェックしたい とします。Admin として、コンソールでゲートウェイキーを発行し、それからそのキーで ランタイムから evaluate フックを呼びます： 
curl https://api.orcarouter.ai/api/v1/firewall/evaluate \
  -H "Authorization: Bearer sk-orca-GATEWAY-KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "tool_name": "shell.exec",
    "arguments": { "command": "rm -rf /" },
    "request_id": "run-42-step-3"
  }'
ファイアウォールはワークスペースのアクティブなポリシーを解決し、 判定を返します — allow、audit、deny、 sanitize、pending_approval、または cap_cost の解決。エージェントはそれに作用 します：allow でディスパッチ、deny でスキップ、pending_approval で承認 id を ポーリング。同じゲートウェイキーが 承認ポーリングと MCP ルートを認証します。
MCP クライアント（Claude Desktop、Cursor、エージェントフレームワーク）を https://api.orcarouter.ai/api/v1/firewall/mcp に向ける？その bearer トークンとして ゲートウェイキーを使います。すべての tools/call はその後、アップストリームに転送 される前に mcp サーフェスで評価されます。

​
5. これがどこに収まるか

ゲートウェイキーはゲートウェイルートを認証します。ポリシーを作成するために 使うコンソールセッションを置き換えません：ポリシーの作成、ルールの編集、MCP サーバーの登録、承認の解決はすべて /api/workspace/firewall/* 上の独自のセッション 下で実行されます（設定、ポリシー、discovered-tool の読み取りはすべてのメンバーに開放； ドライランの test サンドボックスとすべての書き込みは Developer+ を必要とします）。 ゲートウェイキーは、マシン間ランタイムからの判定リクエストと MCP ディスパッチのみを 運びます。

スコープ：キー、ポリシー、ワークスペース

キーの firewall_policy_id とゲートウェイスコープがワークスペース境界とどう 関係するか。

承認

ゲートウェイキーがポーリングして再送信する保留呼び出しのフロー。

承認 webhook

保留された呼び出しを帯域外で解決する HMAC 署名付きコールバック。

MCP サーバー

ゲートウェイエンドポイントの背後で MCP サーバーを登録し統制。

​
6. FAQ

is_firewall_gateway を true に上げることは Admin+ です。フラグを設定する Developer ロールの書き込みはサイレントに false に保たれます（そのため同じ リクエスト上の無関係な改名やクォータ編集は依然として成功します） — キーは単に スコープを運びません。Admin として再作成または編集してください。
提示しているキーがゲートウェイスコープではありません。Admin によって is_firewall_gateway = true で発行されたことを確認します — 通常のリレーキーは これらのルートで常に 403 を受け取ります。§2 を参照。
技術的にはゲートウェイスコープのキーも /v1/* リレートラフィックを提供できますが、 それらを分離してください：モデル用に 1 つのリレーキー（firewall_policy_id が アタッチ）、evaluate/MCP/approval ルート用に 1 つのゲートウェイキー。独立した ローテーション、より小さなブラスト半径。
キーは作成後にマスクされ、ゲートウェイキーの平文を読むことは Admin+ です。発行時に それをコピーしなかった場合、新しいゲートウェイキーを作成し、古いものを引退させます。