メインコンテンツへスキップ
ファイアウォールポリシーがツール呼び出しを判断すると、行を 書き込みます。events フィードはその実行中のログです：評価ごとに 1 つのレコードで、 判定、それが発火したサーフェス、ツール、理由、そしてそれが属した実行/セッションを 運びます。それは、ポリシーを出荷した後に重要な唯一の問いに答える方法です — ファイア ウォールは実際に私が思うことを、私が思う呼び出しでしたのか？ これがあなたの AI ファイアウォールログサーフェスです。すべての allow、すべての deny、すべての保留された承認、すべてのシャドウモードの「would-have」がここに着地し、 フィルタ可能で、それを生成したエージェント実行に相関付けられます。
events フィードの読み取りは Developer+ です。各行はツール呼び出しの引数スナップ ショットのために上限付きの args_summary フィールドを予約するため、このサーフェスは Member 可読のもの（設定、ポリシー、discovered tools、 異常フィード）の上に位置します。これらすべてをコンソールから 設定します — これらはセッション認証されたルートで、リレー呼び出しではありません。

​
1. events フィードに何が着地するか

エンジンが実行するすべての評価が記録されます — ブロックだけではありません。allow と audit は deny と全く同様に行を残すため、フィードは例外ログではなく完全な証跡です。 行の判定は、エージェントが実際に見たものです：
判定意味
allow / audit通された；audit はそれを監視したかったものとしてフラグ。
denyブロックされた — inbound では firewall_blocked（HTTP 400）、mcp ではツールエラー。
sanitize呼び出しの引数からマッチした部分文字列をリダクトして転送。
pending_approval人間のために保留；行は呼び出しがゲートされたことをマーク。
observeポリシーがマッチしなかった — 観察モードのカバレッジギャップ。
フィードでリテラルの cap_cost を決して見ません。cap-cost ルールは評価時に具体的な allow または deny に 解決され、それがログされるものです — 実行が実際に経験した判定です。
シャドウモードでは、強制判定が audit に格下げ され、理由には [shadow] would … が前置されるため、フィードは、ライブに切り替える前に ポリシーが何をブロックしたであろうかを正確に示します。

​
2. 各イベントが何を記録するか

単一のイベントは非正規化されたスナップショットです — 何かに結合し直さずに決定を再構築 するのに十分です：
verdict、surface（inbound / response / mcp / egress）、tool_name、 そして人間向けの reason（「destructive shell command」、「egress to 169.254.169.254 denied」）。マッチしたルールがラベルを持っていた場合、policy_name と rule_label が発火した正確なルールを名指しします — そのため行はあなたが書いた行に 直接戻って指します。
request_id はイベントをリクエストログに結合します；conversation_id はマルチ ターンセッションをグループ化します；agent_run_id（step_id / parent_step_id とともに）はそれを 1 つの完全なエージェント実行とツールを要求した LLM 呼び出しに 結びつけます。これらが、フィードをフラットなリストではなくトレースにするものです — §4 を参照。
token_name、model_name、そして呼び出し元の ip — 呼び出しの背後のキー、 モデル、起点。skill_name は呼び出しが帰属可能だったときに所有 スキルを名指しし、quarantine はスキル隔離の保留を フラグします。
args_summary は上限付きのツール呼び出し引数スナップショットフィールドです （このサーフェスが Developer+ である理由）。egress イベントでは、egress_host が 判断されたアウトバウンド宛先を記録します。
args_summary は上限付きです — 生の引数バイトはフィードにそのまま書き込まれること は決してなく、異常検出を支える retry-loop グループ化ハッシュはサーバー専用です： それは決して API で送られません。

​
3. 具体例 1 つ

エージェントが rm -rf /data で shell.exec 呼び出しを発行し、deny ルールがそれを 捕捉し、その 1 つの決定を見たいとします。フィードを判定とツールでフィルタします： 
# Developer+ console session — GET /api/workspace/firewall/events
curl https://api.orcarouter.ai/api/workspace/firewall/events?verdict=deny&tool=shell.exec \
  -H "Authorization: Bearer $ORCA_CONSOLE_TOKEN"

{
  "events": [
    {
      "verdict": "deny",
      "surface": "response",
      "tool_name": "shell.exec",
      "reason": "destructive shell command",
      "policy_name": "agent-baseline",
      "rule_label": "block destructive shell",
      "model_name": "gpt-4o",
      "token_name": "prod-agent",
      "agent_run_id": "run_abc",
      "request_id": "req_…"
    }
  ],
  "total": 1
}
コンソールは同じ行をフィルタ可能なテーブルとしてレンダリングします — ルートを手で 叩くことはめったにありません。events ビューからフィルタを設定し、実行にドリルダウンし、 エクスポートします；上記の curl は形を示すためだけのものです。
$ORCA_CONSOLE_TOKEN はあなたのセッション / アクセストークンであり、sk-orca-… リレーキーではありません。/api/workspace/firewall/* ルートはコンソール認証され、 ロールゲートされています；/v1/* トラフィックのみがリレーキーを使います。

​
4. 実行とセッションで相関付ける

すべてのイベントが agent_run_id と conversation_id を運ぶ理由は、呼び出しを孤立 して見るのをやめて、このエージェントがその実行全体で何をしたかを尋ね始められる ようにするためです：
フィルタ答える問い
run_id=<run>1 つのエージェント実行のすべての判定 — 完全なアクション証跡。
session_id=<conv>マルチターン会話をまたいだすべての判定。
verdict=deny,pending_approval「何が止められたか保留されたか」ビューを 1 つのクエリで。
surface=egressアウトバウンド宛先の決定のみ — 持ち出しのレンズ。
events リストは since / until（unix 秒）とページングのための limit / skip も 受け入れます。ロールアップビュー — 実行またはセッションごとに 1 行で、判定ごとの 内訳、個別のツールとモデル、初回/最終観測つき — については、コンソールが GET /api/workspace/firewall/events/aggregate?group_by=run（または group_by=session）を 読み、エージェントトレースツリーが /trace/by-run を読みます。両方とも、生のフィードと 同様に Developer+ です。
リクエストログのドロワーから、逆方向にピボットできます： GET /api/workspace/firewall/events/by-request/:request_id は単一のリクエストのもとで キャプチャされたすべてのファイアウォールイベントを返します — 1 つのリクエストが サーフェスをまたいで複数のルールをトリップしたときに便利です。

​
5. 保持と消去

ファイアウォールイベントは独自の保持期間を運びます — 30 日のデフォルトで、 365 日のハード最大にサーバーでクランプされます。各イベントは有効期限とともに 書き込まれ、TTL インデックスによって自動的に期限切れになります；フィード内の何も あなたの保持設定を過ぎて生きません。 消去権リクエストもここにカスケード します：ユーザーの削除は 30 日の猶予期間を開始し、その後彼らの PII がスクラブされ、 彼らのファイアウォールイベントが同じスコープのリクエストログとガードレールマッチと ともにパージされます。

​
次に進む場所

判定

フィード内の各判定が実際に呼び出しに何をしたか。

シャドウモード

強制する前に「would-have」モードでフィードを読む。

ステージ & サーフェス

surface フィールドが名指しする 4 つのサーフェス。

ファイアウォールリファレンス

完全なポリシー、ルール、API リファレンス。
これらのログが現行犯で捕まえるのを助ける脅威については、 データ持ち出しと 危険なツール呼び出しを参照してください。 ファイアウォールがプロンプト/レスポンスのテキストスクリーニングとどうペアになるかに ついては、ファイアウォール + ガードレールを 参照してください。