メインコンテンツへスキップ
ファイアウォールルールを書きました — shell.exec への deny、egress 許可リスト、 rm -rf でのみ発火する引数句 — そして今、それが 1 つの本番ツール呼び出しを変える前に、 それが正確にあなたが思うことをすると知りたいです。ファイアウォールはファイア ウォールルールをテストする3 つの非破壊的な方法を提供し、それぞれが異なる問いに 答えます：

1 つの呼び出しをドライラン

Test サンドボックスは 1 つの合成ツール呼び出しを実エンジンに通し、判定を 返します — 何もディスパッチされず、何もログされません。Developer+。

姿勢を再生

Simulate は最近のトラフィックに対して自律性レベルを再生し、それがブロック するであろう呼び出しの数をカウントします。Member 可読。

ライブトラフィックに対して実行

シャドウモードは実呼び出しに対してポリシー全体を評価しますが、すべての強制 判定を audit に格下げします。ブラスト半径ゼロ。
3 つすべてはコンソール（または /api/workspace/firewall/* 管理ルート。これらは セッション / アクセストークンで認証し、リレーの sk-orca-… キーではありません）で 設定します。テスト中、エージェントの /v1/* リレー呼び出しは決して変わりません。

​
1. ドライラン Test サンドボックスでファイアウォールルールをテストする

Test サンドボックスは最もタイトなループです：1 つの合成ツール呼び出しを渡すと、 実評価エンジンを実行し — 完全なポリシー解決、優先度順に辿られるルール、最初に マッチしたものが勝つ — それから判定、それを生成したルール、人間可読の理由を返します。 呼び出しはドライランです：どのツールにも何もディスパッチされず、events フィードや Discovered-tools インベントリに何も書き込まれません。 それは 1 つの問いに正確に答えます：この正確なツール名とこれらの引数が与えられたとき、 私のポリシーは何を決定するか — そしてどのルールがそれを決定するか？
Test サンドボックスは Developer+ です。保存されていないドラフトポリシーに対して id でプレビューでき、レスポンスはマッチしたポリシー名とルールラベルを表面化するため、 プレーンな読み取りよりも書き込みサーフェスのプレビューに近く位置します — すべての メンバーに開放されている Simulate やその他の読み取りビューとは異なります。

​
具体的なドライラン 1 つ

コマンドが rm -rf を含むときのみ shell.exec を deny すべきルールを追加したと します。一度に 2 つのことを確認したいです：危険なコマンドが deny され、無害なものは 依然として通る。
1

危険な呼び出しをテストする

Security → Firewall で、Test タブを開き、response サーフェスを選び、 ツール名 shell.exec と引数 {"command": "rm -rf /data"} を入力し、実行します。 レスポンスは判定とマッチしたルールを名指しします：
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

無害な呼び出しをテストする

{"command": "ls -la"} で再度実行します。引数句はもはやマッチしないため、ルールは ポリシーデフォルトに落ちます — allow または audit と空の rule_label を見る はずです。rm -rf が deny し ls -la がしなければ、 引数句が正しくスコープされています。
3

アタッチする前にドラフトをプレビューする

トラフィックが現在解決するものではなく特定のドラフトポリシーに対して評価するために policy_id を渡します — そのため、キーをアタッチしたりワークスペースデフォルトに プロモートしたりする前に、新しいポリシーが正しいことを証明できます。
レスポンスの gap を読みます。gap: true は、ポリシーが解決されたが、その中の どのルールも呼び出しにマッチしなかった（そしてワークスペースが観察モードにある） ことを意味します — ツールがすべてのルールをすり抜けてデフォルトに落ちました。それは 出荷前に塞ぐべきカバレッジの穴であり、信頼すべき判定ではありません。
Test サンドボックスはライブ評価と同じサーフェスを使います — inbound、response、 mcp、egress（デフォルト inbound） — そのため各ルールをそれが固定されたサーフェスで テストします。inbound には呼び出し時の引数がないため、sanitize ルールはそこで本番と 全く同様にブロックにエスカレートします；サーフェスがなぜ重要かについては ステージを参照。

​
2. 自律性レベルを適用する前にシミュレートする

Test サンドボックスは1 つの呼び出しをチェックします。Simulate は姿勢レベルの 問いに答えます：このワークスペース全体をより厳格な 自律性レベルに 切り替えたら、最近のトラフィックのどのくらいをブロックするか？ Simulate は候補レベルの deny ルールを直近のファイアウォールイベントに対して再生し、 あるべき影響を返します — ツール名とカウントのみ、決して引数ではありません。それは 読み取り専用かつ Member 可読なので、Developer がそれにコミットする前に、チームの 誰でも tight のブラスト半径をプレビューできます。
  • tight — デフォルト deny、破壊的シェルを deny、フェッチ形のツール（SSRF ベクトル）を deny、PII Shield + Secrets Blocker を強制。Simulate はこの床が 実トラフィックのどのくらいを捕捉するかを示します。
  • balanced — デフォルト audit、破壊的シェルを deny、PII Shield は audit のみ（PII をフラグ）。推奨される開始姿勢。
  • permissive — 観察のみ；何も強制されません。
Simulate は何も変えません — 過去のイベントに対する what-if です。自律性レベルの 適用（Developer+ の書き込み）は実在する編集可能な autonomy_* ポリシーと ガードレール行を具現化し、監査スナップショットからワンクリックで取り消せます。 Simulate でプレビューし、それからカウントが正しく見えたら適用します。

​
3. シャドウモード：ブラスト半径なしでライブトラフィックに対してテスト

Test サンドボックスと Simulate はオフラインのプレビューです。シャドウモードは ライブのものです：実エージェントトラフィックに対してポリシーを評価し、すべての ルールを辿り、判定を選び — それからすべての強制判定（deny、sanitize、 pending_approval）を audit に格下げし、理由に [shadow] would … を前置する ポリシーごとのフラグです。呼び出しは常に通ります；何もブロック、リダクト、保留 されません。 それはevents フィードを、強制をオフにした本番 実行のように読ませます。[shadow] でフィルタすれば、ポリシーがブロックを開始しようと しているすべての呼び出しの完全なリストが — 1 つをブロックする前に手に入ります。
テスト方法何に対して実行答える問い
Test サンドボックス1 つの合成呼び出し「この正確な呼び出しはどの判定を取り、どのルールが決定するか？」
Simulate最近のイベント「より厳格な自律性レベルはいくつの呼び出しをブロックするか？」
シャドウモードライブトラフィック「このポリシーは実際の本番トラフィック全体で何をブロックするか？」
シャドウモードは 3 つの中で最も深いものです — ブラスト半径ゼロでの完全なライブ カバレッジ。それには独自のページがあります： シャドウモードでファイアウォールポリシーをロールアウトするが トグル、[shadow] would … の理由、そして強制への切り替えをガイドします。

​
4. 実践的なテスト順序

3 つのツールはひとつの安全ロールアウトパスに合成されます — 最も安価なチェックを先に、 最も広いカバレッジを最後に：
1

書いたばかりのルールをドライランする

Test を使って、各新しいルールがそれがすべき呼び出しで発火し、すべきでない ものを通すことを確認します — ネガティブケースを含めて。高速、Developer+、何も 永続化されません。
2

姿勢を測る（オプション）

手書きのルールではなく自律性レベルに手を伸ばすなら、レベルを Simulate し、 適用する前に実トラフィックに対するブロックされるであろうカウントを読みます。
3

ライブトラフィックに対してシャドウする

シャドウモードをオンにし、代表的なウィンドウの実呼び出しを流させます。 [shadow] would … イベントを読みます；偽陽性を表面化するルールを締めます — まだ シャドウのまま、ブラスト半径ゼロ。
4

強制する

フィードが期待どおりのものに発火し、そうでないものには発火しないとき、シャドウを オフにします。次の呼び出しが本当に強制します。
テストはポリシーをプレビューし、統制されたスキルではありません。block または quarantine モードのスキルは、シャドウされたポリシーの もとでも依然として強制します — スキルのレビュー処分が勝ちます。ポリシーをシャドウする ことは、スキルの隔離を解除する要求では決してありませんでした。

​
5. API リファレンス

これらの管理ルートはセッション / アクセストークンを使い、ワークスペース スコープです：
メソッドとパスロール目的
POST /api/workspace/firewall/testDeveloper+解決された（またはドラフト policy_id）ポリシーに対して 1 つの合成ツール呼び出しをドライラン。verdict、policy_name、rule_label、reason、gap、shadow_mode を返す。何もディスパッチもログもされない。
GET /api/workspace/firewall/simulate?level=Member最近のイベントに対して自律性レベルを再生；ブロックされるであろうカウントを返す。
GET /api/workspace/firewall/policies/:idMemberポリシーの現在の shadow_mode フラグを読み取り。
PUT /api/workspace/firewall/policiesDeveloper+ポリシーで shadow_mode を切り替え。
Test ボディは surface（デフォルト inbound）、必須の tool_name、オプションの args_json、そして解決を上書きするオプションの policy_id を取ります。

​
次に進む場所

シャドウモード

ライブトラフィックのロールアウト：[shadow] would …、events フィルタ、強制への 切り替え。

引数の検証

ルールをどの引数に絞るか — Test サンドボックスが rm -rf vs ls -la に対して 検証させる句。

判定

テストがテストでなくなったとき、allow / audit / deny / sanitize / pending_approval / cap_cost がそれぞれ何をするか。

Events ログ

シャドウされた判定が着地する場所 — フィルタし、実行とマッチしたルールへドリル ダウン。
これらのテストが行使するルールマッチング文法については、完全な ファイアウォールルールリファレンスを；テストがより広い モデルにどう収まるかについては、 強制モードを参照してください。