メインコンテンツへスキップ
静的なファイアウォールルールは、名指しすることが分かって いた呼び出しを捕捉します。それらは、個別には許可されているが集計では間違っている 呼び出しを捕捉できません — 日曜午前 3 時の 200 回の db.query 呼び出し、タイトな ループで 1 つの失敗するツールを叩くエージェント、このワークスペースが一度も行った ことのないツール間ホップ。各呼び出しはすべてのルールを通ります；パターンが問題です。 ファイアウォール異常検出は挙動層です。ゲートウェイはワークスペースの通常のツール 使用の形を学習し、ライブアクティビティをそれに対してスコアリングし、任意の Member が読めるフィードに逸脱を表面化します。それは、見たことのない形のルールを事前に書かずに、 侵害されたエージェントや暴走ループに気づく方法です。このページはその firewall anomaly detection フィードへの焦点を絞ったランディングです； ファイアウォールの概要が詳細リファレンス です。
異常フィードは検出であり、強制ではありません。それは何がおかしく見えるかを教えます — ブロックしません。パターンが本物のとき、それをルールや レート制限された判定に変えて、次の発生がインラインで 止まるようにします。フィードの読み取りはすべての Member に開放されています；発見を ポリシーに変えることは Developer+です。

​
1. ファイアウォール異常検出が何をフラグするか

4 つのシグナル種類、それぞれが異なる失敗モードに結びついています：
ツールごとの呼び出しボリュームが学習された曜日内時間ベースラインに対して スコアリングされます。ツールは、そのカウントが絶対的な床をクリアかつその時間の ベースラインに対して高く走るとき、またはその z スコアがしきい値を超えるとき、 rate_spike を発火します。曜日内時間（時刻ではなく）でキー付けることは、火曜 14:00 が過去の火曜 14:00 と比較されることを意味するため、正当な平日ピークの トラフィックはスパイクとして読まれず、日曜午前 3 時の同じボリュームは読まれます。
呼び出しカウントではなく累積コストに適用された同じ曜日内時間の比較。支出が 学習されたコスト基準を大きく超えて走るツールは burn_spike として表面化します — 破壊的になる前に高価なエージェントの早期警告シグナルです。
短いウィンドウ内で何度も繰り返す (conversation, tool, arguments) グループ — 回復する代わりに同じ失敗するツール呼び出しを再発行し続けるスタックしたエージェント。 ゆっくりとした正当なポーリングはそれをトリップしません；シグナルはタイトな ループです。
このワークスペースが学習されたベースラインを持たない tool_a → tool_b の連続 遷移。エージェントが例えば crm.read → http.fetch に初めて行くとき、そのエッジは 新規です — まさにデータ持ち出しチェーンが 取る種類のステップです。
異常検出はシーケンスルールを補完します。 シーケンスルールは事前に定義したチェーンにマッチします；novel_path はしなかった 遷移をフラグします — それは、シーケンスルールを書く価値のあるチェーンを発見する方法です。

​
2. 14 日間ベースライン

検出器は固定しきい値ではありません — 学習された基準です。各 (tool, hour-of-week) バケットについて、ゲートウェイは移動する期待呼び出しカウントと コストを保持し、14 日間のルックバック（各曜日内時間バケットの約 2 回の発生 — 週次の形を失わずに単一の異常な日を平滑化するのに十分）からバックフィルされます。 novel_path は並行する遷移ベースラインを使います：その曜日内時間における各 tool_a → tool_b エッジの学習された発生カウントです。 真新しいワークスペースにはまだベースラインがありません。それで問題ありません：学習された 基準がなければ、ボリューム検出器は絶対的な床にフォールバックするため、明白な洪水は 時間ごとの基準が埋まる間も初日に依然として捕捉されます。
シグナル何から学習するか
rate_spike / burn_spike(tool, hour-of-week) ごとのカウントとコスト、14 日間移動。
novel_path(tool_a → tool_b, hour-of-week) ごとの遷移カウント。
retry_loopベースラインなし — (conversation, tool, args) 上のウィンドウ化された繰り返ししきい値。
フィードはツール名、リダクトされたトークン id、カウントのみを報告します。生の API キー id は決して表示されません — 各アイテムは呼び出しトークンの一方向ダイジェストを 運ぶため、フィードがその背後のキーを決して漏らさずに 2 つの異常を区別できます。

​
3. 具体的な読み取り 1 つ

エージェントキーがループを開始するとします。コンソールの Security → Firewall → Anomalies でフィードを引き出すか、直接読みます — 任意の Member ができます： 
curl https://api.orcarouter.ai/api/workspace/firewall/anomalies \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN"

{
  "data": {
    "items": [
      {
        "id": "3f1c9a7b0e2d4a86",
        "kind": "retry_loop",
        "tool_name": "db.query",
        "token_id_redacted": "sk-***-9f2a",
        "count": 412,
        "baseline": 0,
        "z_score": 0,
        "suggested_action": "rate_limit",
        "first_seen": 1749470400,
        "last_seen": 1749470520
      }
    ],
    "snoozed_until": 0
  }
}
retry_loop アイテムは baseline や z_score を運びません（それらのフィールドは 0 のまま — それらはボリューム/コスト検出器に属します）、そして同じツール上の 2 つの 別個のループが 1 行で衝突しないよう、安定した不透明な id を運びます。rate_spike は 逆です：学習された baseline と z_score を報告し、id を空のままにします。
$ORCA_SESSION_TOKEN はあなたのコンソールセッション / アクセストークン — すべての /api/workspace/firewall/* 管理ルートと同じ認証です。それはリレーの sk-orca-… キー ではなく（それらは /v1/* モデル呼び出し専用です）、ファイアウォールゲートウェイキー でもありません。このルート上のリレーキーは拒否されます。
各アイテムはツール、リダクトされたトークン、いくつの呼び出しが発火したか、z スコア （ボリューム/コストシグナルのみ）、そして suggested_action（rate_limit、block_tool、 review）を名指しします。ここから行動します：ツールに deny ルールを 落とす、その引数を検証する、または events ログを開いてエージェントが正確に何をしたかを 見ます。

​
4. フィードをスヌーズする

既知の負荷テストや計画されたバックフィルはフィードを点灯させます。ノイズを追いかける のではなく、それをスヌーズします — 最大 7 日間： 
curl -X POST https://api.orcarouter.ai/api/workspace/firewall/anomalies/snooze \
  -H "Authorization: Bearer $ORCA_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"until": 1749643200}'
スヌーズがアクティブな間、フィードはアイテムを返さず snoozed_until を報告します； 締め切りが過ぎた瞬間に自身をクリアします。上限はハードな天井です — 打ち間違えたまたは 敵対的なさらに先の until はクランプされるため、異常検出を無期限にサイレントにできません。 過去または現在の until を POST すると、既存のスヌーズをクリアします。
フィードの読み取りは Member のアクションです；それをスヌーズすることは Developer+ です — ワークスペース全体の安全シグナルをミュートすることは、読み取り ではなく書き込みです。

​
5. RBAC 概観

分析サーフェスは通常の読み取り/行動の線に沿って分かれます：
アクションロール
異常フィードを読み取りMember
設定、ポリシー、discovered tools を読み取りMember
フィードをスヌーズDeveloper+
Events、runs、aggregate、traceDeveloper+
発見からルールを作成Developer+
より軽い集計ビュー — 設定、ポリシー、そして discovered-tools カバレッジマップ — も Member の 読み取りです；行レベルの events と runs の詳細は、 呼び出しごとの引数データを運ぶため Developer+ です。

​
6. シグナルからポリシーへ

フィードはループの始まりであり、終わりではありません：
1

パターンを見つける

novel_path または rate_spike が予期しなかった形を示します。それを events ログに対して読み、一度きりではなく本物で あることを確認します。
2

ルールを書く

発見を強制に変えます — ブロック、 引数句、チェーンのための シーケンスルール、または burn のための コスト上限。
3

安全にロールアウトする

ルールをまずシャドウモードのもとで着地させ、 1 つの呼び出しもブロックする前にそのブラスト半径を測定し、それから強制します。

​
次に進む場所

ファイアウォールの概要

完全な異常検出リファレンスとポリシープレーンの残り。

Events ログ

異常からその背後の正確な呼び出しへドリルダウン。

ツールをブロック

発見を強制ルールに変える。

強制モード

検出、audit、シャドウ、強制がどう組み合わさるか。
これらのシグナルが暴く脅威については、 データ持ち出しと 過剰なエージェンシーを参照してください。