メインコンテンツへスキップ
ルールが本番トラフィックをブロックする前に、それが適切なものに発火し、他には発火しない ことを確認したいものです。OrcaRouter は 3 つの姿勢 — observe、shadow、 enforce — を提供し、すべてのステップで可視性を持ちながら段階的にロールアウトでき、 サプライズがありません。 このページでは各姿勢がメカニカルに何を意味するか、それらをどう移動するか、そして 自律性レベルがこれらすべてをひとつのステップで設定する方法を説明します。

​
1. 3 つの姿勢の概要

姿勢トラフィックへの影響メカニズム使用タイミング
Observeすべてのトラフィックが許可されます；ポリシーがない呼び出しはカバレッジギャップとしてログされますワークスペースレベルの observe mode がオン；ガードレールルールが flag アクションを使用；ファイアウォールの default_verdict が auditベースライン探索 — ひとつのルールを書く前にエージェントが実際に何をするかを理解する
Shadowトラフィックは許可されます；ポリシーが評価し、ブロックになるものが [shadow] would … としてログされますファイアウォールポリシーのポリシーごとの shadow_mode フラグがオン安全な本番前検証 — ポリシーがトラフィックに触れる前に正しく発火することを確認する
Enforce実際の判定が適用されます — deny がブロックし、sanitize がリダクトし、pending_approval が保留しますShadow mode がオフ；ガードレールアクションが block / mask に設定；ファイアウォール判定がライブShadow でポリシーを検証した後の本番強制
ロール要件。 すべてのワークスペースメンバーはポリシー、設定、discovered-tools ビューを読み取れます；ファイアウォールの Events と Runs フィードには Developer ロールが必要です。設定、ポリシーアクション、または shadow_mode の 変更にも Developer 以上が必要です。

​
2. Observe 姿勢 — ルールを書く前に測定する

Observe 姿勢はひとつのスイッチではありません。一緒に「すべてを許可し、すべてを記録する」 を生成する 3 つの独立したメカニズムの組み合わせです：

​
ファイアウォール observe mode（ワークスペース設定）

ツール呼び出しがまったくポリシーに解決されない — キーアタッチメントもワークスペース デフォルトも — 場合、ファイアウォールのワークスペースレベルの observe mode が 何が起きるかを決定します：
  • Observe mode がオン： 呼び出しは許可され、カバレッジギャップとしてログされます。 Discovered Tools ビューはこれらのギャップイベントから埋まり、エージェントがどの ツールを実行しているかを正確に示します — ルールがそれらをカバーせずに。
  • Observe mode がオフ： 呼び出しはサイレントに許可されます — 機能を一度も 有効化していないワークスペースとバイト単位で同一です。
Observe mode はギャップ検出サーフェスです。ポリシーが解決されない場合にのみ発火します。 audit に設定されたポリシーを持つこととは同じではありません。

​
ファイアウォール audit 判定（ポリシーごとのデフォルト）

ポリシーが解決されるが、ツール呼び出しにマッチするルールがない場合、ポリシーの default_verdict が適用されます。default_verdict のデフォルト値は audit です — 呼び出しを許可し、レビュー用に記録します。ルールも設定変更もない新しいポリシーは 何もブロックせず、サイレントに何も許可しません：見るすべてを audit します。 audit は通常のルール判定でもあります。マッチして audit を生成するルールは、 呼び出しを通過させ記録します — ファイアウォールのガードレール audit モードのアナログです。

​
ガードレール flag アクション（ルールごとのアクション）

ガードレール側では、flag アクションは observe の等価物です：ルールが発火し、 マッチが Matches フィードに記録され、リクエストは変更されずに続きます。ブロックなし。 リダクションなし。block や mask にコミットする前にルールを測定したいとき — どのくらいの頻度で何に発火するかを確認するために — flag を使用します。
これら 3 つが一緒に observe 姿勢を生成します：observe mode がカバーされていないツール 呼び出しを捕捉します；audit 判定がポリシー下にあるがまだ特定のルール下にないツール 呼び出しをカバーします；flag アクションがまだ強制する準備ができていないガードレール チェックをカバーします。

​
3. Shadow 姿勢 — 強制する前に検証する

Shadow mode はファイアウォールポリシーのポリシーごとのフラグ（shadow_mode: true） です。オンの場合：
  • ポリシーはすべてのツール呼び出しを本番と全く同様に評価します — ルールがマッチし、 判定が計算され、引数述語がテストされます。
  • すべての強制判定（deny、sanitize、pending_approval）は、ツールに到達する前に audit に格下げされます。
  • ログされた理由には [shadow] would … が前置されるため、イベントフィードでブロック、 sanitize、保留されたものが正確に確認できます。
Shadow mode は安全なロールアウトスイッチです。ポリシーを書き、Shadow をオンにし、 実際のトラフィックをそれに向け、数時間または数日間イベントと実行ビューを監視し、 ポリシーが適切なツールに発火し、予期しないものには発火しないことを確認してから、 Shadow モードをオフにして強制を開始します。
ガードレールにはポリシーレベルの shadow_mode 等価物がありません — block または mask に切り替える前に個々のガードレールチェックを観察するために、ルールごとに flag アクションを使用してください。

​
4. Enforce 姿勢 — 実際の判定、実際の結果

Enforce 姿勢では、何も格下げされません：
  • ファイアウォール deny → エージェントはツールエラー（MCP）または HTTP 400 firewall_blocked（inbound サーフェス）を見ます。エラーはツールと理由を示します。 skip-retry とマークされます。
  • ファイアウォール sanitize → マッチした部分文字列がツール引数からリダクトされ、 クリーンな呼び出しが転送されます。
  • ファイアウォール pending_approval → 呼び出しが保留されます；エージェントは HTTP 400 firewall_approval_pending とポーリングする承認 id を受け取ります。
  • ガードレール block → HTTP 400 guardrail_blocked、発火したガードレールと ルールを示します。クォータなし。
  • ガードレール mask → マッチがリダクトされます（例：jane@acme.com → [EMAIL]） そしてリクエストはサニタイズされたテキストで継続します。
Enforce 姿勢に達するには：ファイアウォールポリシーの shadow_mode をオフにし、 flag で観察していたガードレールルールアクションを適切に block または mask に 変更します。

​
5. 推奨されるロールアウト

1

Observe — エージェントが何をするかを発見する

ワークスペースの observe mode をオンにします（PUT /api/workspace/firewall/settings、firewall_observe_mode: true）。ファイアウォールは ポリシーなし（または default_verdict が audit のポリシー）のままにします。 測定したいガードレールルールに flag アクションを追加します。Discovered Tools ビューが、エージェントが行うすべてのツール呼び出しで埋まり、 covered または gap とフラグされるのを見てください。これを最初のポリシー ルールを書くための入力として使用します — 仮想のトラフィックではなく、実際の トラフィックのためにルールを書いています。Discovered Tools ビューが安定し、意図的なルールを書くのに十分なデータが得られる まで実行させます。
2

Shadow — 強制前に検証する

shadow_mode: true でファイアウォールポリシーを作成します。統制したいキーに アタッチします（またはワークスペースデフォルトとして設定します）。ガードレールについては、 このステージでルールアクションを flag のままにします。ポリシーはすべての実際のツール呼び出しを評価し、何をするかをログします。 Events と Runs ビューを開き、[shadow] プレフィックスでフィルタします。 確認します：
  • 意図したツールと引数パターンに発火する。
  • 許可したいものには発火しない（偽陽性）。
ルールをチューニングし、再観察し、繰り返します。Shadow ログが正しく見えたら、 次に進みます。
3

Enforce — スイッチを切り替える

ポリシーで shadow_mode: false を設定します。flag で観察していたガードレール ルールのアクションを適切に block または mask に変更します。最初の 1 時間の予期しないブロックについて Events フィードを監視します。 自律性監査ログの Undo アクションにより、ロールバックが必要な場合に以前の 状態をワンクリックで復元できます。

​
6. 自律性レベル — すべてを一度に設定する

ポリシーをルールごとにチューニングするのは精密な道です。自律性レベルは 高速な道です — ひとつのコントロールがワークスペースのファイアウォールおよび ガードレール姿勢をひとつのトランザクションでアトミックに設定し、ワンクリックの 取り消しが可能です：
レベル生成される姿勢
permissiveObserve 姿勢：強制ポリシーなし、ガードレールなし、ワークスペース observe mode オン — すべてを見て、何もブロックしません。上記の Observe ステップにマッピングされます。
balancedデフォルト判定 audit、ただし破壊的シェルは denied；PII Shield が audit-only モードで実行（PII をフラグ）；observe mode オフ。トラフィック形状を把握したら推奨される開始姿勢。
tight完全強制：デフォルト deny、破壊的シェルと SSRF egress が denied；PII Shield + Secrets Blocker ガードレールが強制（リクエストをスクリーニング）；observe mode オフ。
POST /api/workspace/firewall/autonomy で適用します（Developer+）。 Simulate エンドポイント（GET /api/workspace/firewall/simulate?level=）は 適用する前にレベル変更が何をするかをプレビューします。
自律性レベルは上記で説明したものと同じメカニズムの上の便利なレイヤーです — default_verdict、observe mode、ファイアウォールルール、ガードレールルール アクションを設定します。shadow_mode は切り替えません；それは手動のポリシーごとの コントロールのままです。レベルを適用した後にいつでも個々の設定をオーバーライドできます。

​
7. メカニズムマップ — どの設定が何をするか

このテーブルは権威あるリファレンスです。4 つの用語は異なります — 混同しないでください：
用語種類何を制御するか
Observe modeワークスペース設定ツール呼び出しがポリシーなしに解決された場合の動作。オン → ギャップとしてログ（Discovered Tools）。オフ → サイレント allow。
audit 判定ポリシー / ルール判定ポリシーの下にあるツール呼び出しのマッチ（またはデフォルトに落ちる）場合の動作。Allow + 記録。デフォルトの default_verdict。
flag アクションガードレールルールアクションガードレールチェックはトラフィックを許可し、マッチを記録します。ガードレールの強制なし observe アクション。
shadow_modeファイアウォールポリシーごとのフラグすべての強制判定（deny/sanitize/pending_approval）を audit に格下げし、理由に [shadow] would … を前置します。

セキュアエージェント ベースライン

推奨される開始姿勢とゼロトラストエージェントセキュリティの 5 分間セットアップ。

エージェントファイアウォール

ポリシー、ルール、判定、shadow mode、MCP ゲートウェイの完全リファレンス。
強制モードはバイナリのオン/オフではありません。observe → shadow → enforce を 通じて移動すれば、ルールは実際のトラフィックでブロックする前に検証されます。