メインコンテンツへスキップ
api.orcarouter.ai でエージェントが使うキーがあり、そのキーが行うすべての ツール呼び出しを統制したい — ブロック、audit、サニタイズ、承認のための保留 — エージェントのコードに触れることなく。それが 2 ステップのエージェント ファイアウォールセットアップです：ファイアウォールポリシーを 一度作成し、キーをそれに向けます。次の呼び出しから、キーが発行するすべての ツールがゲートウェイでポリシーに対してチェックされます。 このページは作成・アタッチのパスです。完全なポリシーモデル（サーフェス、判定、 解決）についてはファイアウォールの概要を、ルール文法に ついてはファイアウォールルールを参照してください。
すべてのポリシーとキーの設定はコンソール（または /api/workspace/firewall/* 管理ルート。これらはセッション / アクセストークンを使い、リレーの sk-orca-… キー ではありません）で行われます。エージェントの /v1/* 呼び出しのみがリレーキーを 使います。ポリシーの作成とアタッチは Developer+ のアクションです。

​
1. エージェントファイアウォールセットアップ概観

ファイアウォールポリシーは名前付きの、ワークスペーススコープのオブジェクト です：順序付けられたルールのリストと、どのルールもマッチしないすべてのための デフォルト判定です。キーはその firewall_policy_id フィールドを通じてポリシーに オプトインします。スタックの他の何も変わりません。

ポリシーを作成

名前を付け、デフォルト判定を選び、ルールを追加 — または自律性レベル / プリセットからシードして編集します。

キーをアタッチ

キーの firewall_policy_id をポリシーに設定するか、ポリシーをワークスペース デフォルトにマークして、すべてのアタッチされていないキーがそれを継承するように します。

​
2. コンソールでポリシーを作成する

  1. Security → Firewall → Policies を開き、New policy を選びます。
  2. 名前を付け（ワークスペース内で一意）、Enabled をオンのままにします。
  3. デフォルト判定を選びます — §3 を参照。
  4. ルールエディタでルールを追加するか、空のまま開始して後で Discovered tools に実トラフィックからの作成を 駆動させます。
  5. 保存します。ポリシーは存在しますが、キーがそれに向けられるか、ワークスペース デフォルトにするまで何も統制しません。
最初にルールを手作成したくない？自律性レベルを 適用します（balanced が推奨される開始点です） — 実在する編集可能なポリシーおよび ガードレール行を具現化し、後でチューニングできます。または組み込みのプリセットから ルールを開始して編集します。いずれにせよ、同じ場所に辿り着きます：キーにアタッチする 名前付きポリシーです。

​
3. デフォルト判定を選ぶ

デフォルト判定は、ポリシーがどのルールもマッチしないツール呼び出しに 対して行うことです。それはあなたの姿勢の床です。ちょうど 3 つの値を受け入れます：
default_verdictどのルールもマッチしないとき…
audit (デフォルト)呼び出しを許可しますが、記録します。すべてを観察し、何もブロックしません — 安全な開始点。
allow許可してログ、レビューレコードなし。
denyルールが明示的に許可しないものをブロック — allow ルールと組み合わせるデフォルト deny の姿勢。
deny はデフォルト deny です：ルールが明示的に許可しないツール呼び出しは ブロックされます。強力ですが、許可リストし忘れた呼び出しを止めてしまいます。 デフォルト deny のポリシーはまずシャドウモードの もとでロールアウトし、強制する前に events フィードを監視してください。
ルールが生成できる判定（allow、audit、deny、sanitize、 pending_approval、cap_cost）は判定で カバーされています — デフォルト判定は上記の 3 つに限定されます。

​
4. ポリシーをキーにアタッチする

キーはその firewall_policy_id を通じてポリシーにオプトインします。 コンソールで：
  1. Keys を開き、エージェントが使うキーを編集します。
  2. Firewall policy を作成したポリシーに設定します（これは firewall_policy_id を書き込みます）。
  3. 保存します。そのキーが行う次の呼び出しが統制されます。
バインディングはキー上、ゲートウェイ内にあります — エージェントは同じ Authorization: Bearer sk-orca-… と同じリクエストボディを送り続けます。 エージェントのツール呼び出しコードに変更はありません。 
# Your agent's relay call is unchanged. The attached policy is enforced
# at the gateway before any tool call in the response is dispatched.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
ルールが inbound サーフェスでツール呼び出しを deny すると、その呼び出しは ツールと理由を名指しするコード firewall_blocked の HTTP 400 として返って きます — ブロックがどう見えるかを参照。

​
5. 解決：アタッチ済み → ワークスペースデフォルト

任意のツール呼び出しについて、ゲートウェイはこの順序でどのポリシーが適用されるかを 解決します：
呼び出し元キーの firewall_policy_id が存在し有効なポリシーを指している 場合、そのポリシーが適用されます。
それ以外の場合、ワークスペースの有効な is_default ポリシーが適用されます （設定されている場合）。ワークスペースごとに最大ひとつのポリシーがデフォルトに なれます；新しいデフォルトをプロモートすると、同じトランザクション内で古いものが 降格されます。
アタッチメントもデフォルトもないということはポリシーがないことを意味します。 観察モードがオンの場合、呼び出しは許可され カバレッジギャップとしてログされます；オフの場合、呼び出しはサイレントに 許可されます。
無効化されたアタッチ済みポリシーはワークスペースデフォルトにフォールバック します — 強制をオフにはしません。（これは ガードレールとは異なります。 ガードレールでは無効化されたアタッチメントはnone に解決されます。）キーを ファイアウォールのスコープから外すには、それをデタッチします（firewall_policy_id を 0 に設定）、ポリシーをただ無効にするのではなく。
ポリシーを、アタッチされていないすべてのキーのデフォルトにするには、キーを 1 つずつ アタッチするのではなく、それを編集してワークスペースデフォルトに設定します — ポリシーの管理を参照。

​
6. 効果を確認する

それに依存する前に、ポリシーが期待どおりに発火することを確認します：
  • テストする — サンドボックスの Test タブはサンプルのツール呼び出しに 対してポリシーをドライランし、判定、マッチしたルール、理由を返します。何も ディスパッチも永続化もされません。 ルールのテストを参照。
  • events フィードを監視する — キーがライブトラフィックを受け取ると、 Events が各評価を、判定、サーフェス、ツール、 実行でフィルタ可能に表示します。
強制ポリシーはまずシャドウモードの背後で ロールアウトします：本番と全く同様に評価しログを取りますが、すべての強制判定を audit に格下げし、理由に [shadow] would … を前置します。events フィードが 期待どおりのものに発火し、そうでないものには発火しないことを示したら、シャドウを オフにします。

​
次に進む場所

ルールの作成

完全なマッチング言語 — ツールグロブ、引数句、egress リスト、サニタイザ。

ツール許可リスト

deny デフォルト判定を明示的な allow ルールと組み合わせます。

ポリシーの管理

デフォルト、有効化/無効化、バージョニング、リバート。

ゼロトラストの理由

テキストだけでなくアクションを統制することがなぜエージェントにとって重要か。
ポリシーが止めるべき脅威については、 危険なツール呼び出しと 過剰なエージェンシーを参照してください。