メインコンテンツへスキップ
ファイアウォールルールが pending_approval 判定を返すと、エージェントのツール呼び出しは ディスパッチされる代わりに保留されます — それは今や人間を待っています。このページは レビュアーのためのものです：コンソールからエージェントのツール呼び出しの保留を どう承認するか（または拒否するか）、キューが何を表示するか、そして OrcaRouter が どう 2 人のレビュアーが同じ決定で衝突するのを防ぐか。 それはヒューマンインザループの解決半分です。呼び出しがなぜ保留されるか、そして 保留されたエージェントがその後どう再送信するかについては、 判定とより深い 承認リファレンスを参照してください。コンソールの 代わりに独自のシステムから解決するには、 承認 webhookを参照してください。

​
1. レビュアーの席から見た保留呼び出しのライフサイクル

保留された呼び出しは短い帯域外ループです。あなたの仕事は中間のステップです：
1

呼び出しが保留される

ルールが pending_approval に解決します。リレーはコード firewall_approval_pending と承認 id を持つ HTTP 400 を返します；呼び出しは ツールに決して到達しません。エージェントはその id でポーリングを開始します。
2

あなたが解決する

Approvals キューを開き、呼び出しがなぜ保留されたかを読み、それを承認 または拒否します — このページの焦点です。
3

エージェントが進む（または停止する）

承認で、エージェントは単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに 元の呼び出しを再送信し、ゲートウェイはその 1 回限り通します。拒否では、呼び出しは ブロックされたままになります。
保留の解決は Developer+ にゲートされています — ファイアウォール Events フィードと 同じゲートです。より低いロールはファイアウォールポリシー、設定、discovered tools を 読めますが、Developer 以上のロールのみが承認キューをリストしたり保留されたツール呼び出しを 承認/拒否したりできます。 ロールとスコープを参照。

​
2. 保留中キューをリストする

Approvals タブは GET /api/workspace/firewall/approvals を読みます。フィルタなしでは pending キューを最古順で返します — そのため最も長く待っている呼び出しが上に 位置し、バックログを順に処理します。 
GET /api/workspace/firewall/approvals?state=pending
state は重要な唯一のフィルタです。値は承認のライフサイクルにマップされます：
state返される承認
pending (デフォルト)保留、決定待ち — あなたの作業キュー。
approvedすでに通された。
rejectedすでにブロックされた。
これはセッション上のコンソールルートです — sk-orca-… リレーキーではなく ダッシュボードから設定しレビューします。リレーキーは /v1/* モデル呼び出し用です； ファイアウォール管理はコンソールログインのもとで実行されます。

​
3. 呼び出しがなぜ保留されたかを読む

各行はレビュアーが必要とする決定入力を運びます — ツール名（tool_name）、 引数フィンガープリント（args_hash、正規化された呼び出し引数の SHA-256 — 生の 引数値は承認に保存されません）、リクエスト id、そしてポリシー、ルール、発火した句を 名指しするプレーンな英語の来歴行：
マッチしたルールが属する名前付きポリシーで、ワークスペーススコープで解決される ため、古い id が別のテナントのポリシー名を表面化することは決してありません。
ルールのラベルと 1 行の「なぜ」記述子 — 例：command contains rm -rf、または グロブのみのルールの tool matches "http_fetch"。これがキューの「Held because…」 行をレンダリングします。
この承認が作成された時点またはそれ以降にマッチしたルールが編集されたとき true。ライブのラベルと句はその後抑制され（それらはもはや実際に呼び出しを保留した ものを反映していないかもしれません）、キューは古い来歴の代わりに「rule since changed」の注記を表示します。ツール名と引数 — 本当の決定入力 — は常に表示されます。
rule_changed は意図的な誠実シグナルであり、エラーではありません。呼び出しがキューに ある間に誰かがファイアウォールルールを編集すると、OrcaRouter はもはやマッチしない来歴を 表示するより、間違っている可能性のある理由を隠すことを選びます。その場合は ツール名とポリシー名（依然として表示）で決定してください。

​
4. 承認または拒否

解決は PATCH /api/workspace/firewall/approvals/:id を、approved または rejected の decision とオプションの reason とともに送ります。ボタンをクリックすると コンソールがそれをあなたのために行います；形は： 
PATCH /api/workspace/firewall/approvals/507f1f77bcf86cd799439011
Content-Type: application/json

{ "decision": "approved", "reason": "verified target host with the on-call" }
  • approved → 保留された呼び出しは進めます。エージェントの次の再送信は、単回使用の 承認ヘッダーを運び、一度通されます。
  • rejected → 呼び出しはブロックされたままになります。エージェントは拒否を見て、 別のパスを選んだり、ユーザーに尋ねたり、停止したりできます。
decision は閉じた {approved, rejected} セットに対して検証されます — それ以外は すべて拒否されます。reason は決定とともに記録され、アクター、ツール名、リクエスト id とともにファイアウォール監査ログに書き込まれます。
すべての解決は、誰が決定したか、決定、理由を名指しするワークスペース監査行を 書き込みます。コンソールの解決は人間のアクターを記録します； webhookの解決はシステムアクターを記録 します。解決の来歴が決してサイレントにドロップされることはありません。

​
5. 最初のライターが勝つ：二重解決なし

保留中の承認はレースされる可能性があります — コンソール内の 2 人のレビュアー、または コンソールのクリックとwebhook コールバックが 一緒に到着。OrcaRouter はこれを単一の最初のライターが勝つルールで解決します：
  • 決定は、承認がまだ pending である間のみ発火するアトミックな条件付き更新です。 最初のライターが勝ち、決定を適用します。
  • 後のすべてのライターは「すでに解決済み」を観測し、冪等の no-op として扱われ ます — エラーではなく、すでに解決されたドキュメントとともに HTTP 200 を受け取り ます。
レスポンスはあなたがどちら側だったかを教えます： 
{
  "resolved": false,
  "already_resolved": true,
  "approval": { "state": "approved", "decision": "approved", "...": "..." }
}
resolved: true はあなたの呼び出しが決定を適用したことを意味します； already_resolved: true は誰か（または何らかの webhook）が先に到達し、あなたが その結果を見ていることを意味します。いずれにせよ、キューはひとつの一貫した状態に 調停されます。
解決は冪等なので、不安定なネットワークやダブルクリックが保留を破損させたり決定を 反転させたりできません。最初の承認/拒否のみがカウントされます；その後のすべては 結果を読み返すだけです。

​
6. キューを通る具体的なパス

balanced 自律性のワークスペースが、ルールが command contains rm -rf にマッチしたため エージェントの shell.exec 呼び出しを保留します。レビュアーとしてあなたは：
  1. Approvals を開く — 保留された shell.exec が最古順の pending リストの上に 位置します。
  2. 行を読む：ツール shell.exec、args_hash フィンガープリント、リクエスト id、 そして「Held because… command contains rm -rf」行（マッチしたルールの句から レンダリング）。rule_changed フラグがないため、来歴は最新です。
  3. ターゲットはスクラッチディレクトリなので、理由とともに承認します。
  4. あなたの PATCH は resolved: true を返します；エージェントの次のポーリングが approved を見て、単回使用ヘッダーとともに再送信し、コマンドがちょうど一度 実行されます。
チームメイトが 1 秒早くそれを承認していたら、あなたのクリックは彼らの決定とともに already_resolved: true を返したでしょう — 害なし、二重実行なし。

​
次に進む場所

承認リファレンス

完全な HITL ループ：保留、ポーリング、再送信、単回使用ヘッダー。

承認 webhook

HMAC 署名付きコールバックで独自のシステムから保留を解決。

判定

pending_approval が 6 つのファイアウォール判定の中のどこに位置するか。

Events ログ

解決された呼び出しの下流の結果をフィードで確認。
これらの保留が捕捉すべきリスクについては、 危険なツール呼び出しと 過剰なエージェンシーを参照してください。