メインコンテンツへスキップ
あなたには、本番の前に置きたいポリシーがあります。恐怖はポリシーではありません — それを オンにして、エージェントが実際に必要とするツールをブロックしたり、アプリが依存する フィールドをマスクしたりすることを発見することです。修正はサンドボックスでのさらなる テストではありません；それは、何も壊せない姿勢で実トラフィックに対してロールアウト し、何が発火するかを見てからだけ締めることです。 このレシピがそのロールアウトです：observe → shadow → enforce、自律性は tight の前に balanced。あなたはずっとコンソール（または REST API）に留まります；エージェントは 以前と全く同様に https://api.orcarouter.ai/v1/... を呼び続けます。
モデルは初めてですか？ 各姿勢が機械的に何をするかは 強制モードを、各自律性レベルが何を設定するかは Secure Agents ベースラインを読んで ください。このページはシーケンス — スイッチを切り替える順序です。

​
1. 3 つの動きで AI セキュリティロールアウト

ロールアウト全体は、3 つのステップで自律性を安全性と交換し、それぞれが次の前に 実トラフィックに対して検証されます：

Observe

すべてを許可し、すべてをログします。カバーされていないツール呼び出しは Discovered Tools に着地します；ガードレールの flag ルールはトラフィックを変えずにマッチを 記録します。あなたはエージェントの実際の形を学びます。

Shadow

実在のポリシーがすべての呼び出しを評価しますが、すべての強制判定は audit に 格下げされ、[shadow] would … とログされます。何も実際にはブロックされずに、何が ブロックされるかを正確に見ます。

Enforce

シャドウオフ。deny はブロックし、mask はリダクトし、pending_approval は保留 します。自律性は広い（balanced）からタイト（tight）へ進み、あなたのエージェントは 統制されます。
規律が要点です：あなたは、自分のトラフィックに対してシャドウで発火するのをまず見て いないルールを決して強制しません。

​
2. 動き 1 — observe（自律性 = permissive）

可能な限り広く始めます。Firewall → Posture（Developer+）から、あるいは POST /api/workspace/firewall/autonomy で permissive 自律性レベルを適用します。 これはワークスペースの観察モードを有効にし、強制ポリシーを残さないため、すべての 呼び出しが許可され、すべてのカバーされていない呼び出しがカバレッジギャップとして ログされます。 
# Console: Firewall → Posture → apply "permissive"
# or, via the REST API on your session token:
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "permissive"}'
/api/workspace/firewall/* ルートは、リレー sk-orca-... キーではなく、あなたの コンソールセッション / アクセストークンで実行されます。自律性レベルの適用は ワークスペースの書き込みです — Developer+。リレーキーを使うのは /v1/* モデル 呼び出しだけです。
さて、実トラフィックをそこに向けて実行させます。2 つのフィードを監視します：
  • Firewall → Discovered Tools（Member） — あなたのエージェントが呼び出すすべての ツール、covered または gap とフラグ。これがあなたのルールの入力です：あなたは 仮説ではなく、実際に起こるトラフィックのためにポリシーを書こうとしています。
  • Guardrails → Matches（Member） — flag アクションのルールを追加していれば、それらが 記録するすべてのマッチを、リクエストに触れずに。
Discovered Tools が新しいツールの表面化を止めるまで実行させます。その安定したリストが、 あなたのルール作成仕様です。

​
3. 動き 2 — shadow（実在のポリシー、ブロックゼロ）

さて、あなたが実際に望むポリシーを作成し — ツールグロブ、引数句、egress リスト、 cap_cost 上限 — アタッチする前に shadow_mode をオンにします。（ルールは ファイアウォールルールから構築します；完全なポリシー モデルはファイアウォールリファレンスにあります。） 
{
  "name": "prod-rollout",
  "enabled": true,
  "shadow_mode": true,
  "default_verdict": "audit",
  "rules": [
    { "priority": 10, "tool_name_glob": "shell.exec", "verdict": "deny" },
    { "priority": 20, "tool_name_glob": "*",          "verdict": "cap_cost", "cap_cost_cents": 1000 }
  ]
}
shadow_mode: true だと、その deny とその cap_cost は両方とも評価時に audit に 格下げされます — エンジンは実際の判定を計算し、[shadow] would … を前置してログし、 呼び出しを通します。ポリシーを、ロールアウトするキーにアタッチする（キーに firewall_policy_id を設定）か、ワークスペースデフォルトにします。 それから Firewall → Events / Runs（Developer+）を [shadow] プレフィックスで フィルタして読み、両側を確認します：
すべての shell.exec 呼び出しが [shadow] would deny を示します。上限を超える すべての run が [shadow] would cap_cost を示します。ポリシーは、それのために 構築したトラフィックを見ています。
正当なツールが would-block 判定で現れません。これが誤検出チェックです — シャドウが 存在する理由です。必要とするツールがフラグされた場合、強制する前にルールを修正して 再監視します。
ガードレールにはポリシーレベルのシャドウはありません。同等物はルールごとの flag アクションです：Matches フィードにマッチを記録し、何も変えないため、コンテンツルールを block または mask に切り替える前に測定できます。この同じ動きで、あなたのガードレール ルールを flag として実行します。

​
4. 動き 3 — enforce（自律性 balanced、それから tight）

シャドウログが正しく見えたら、1 つではなく2 段階で強制します。いきなりデフォルト deny に飛ばないでください。 まず、balanced。 これが推奨される最初の強制姿勢です：ファイアウォールのデフォルト 判定は audit ですが、最も破壊的なアクション（破壊的シェルなど）は deny され、 PII Shield ガードレールは audit のみで実行されます — PII をまだマスクせずにflag します。あなたはいまや、残りを観察しながら最悪のものをブロックしています。 同じ動きで、あなた自身のポリシーの shadow_mode をオフにして、その deny / cap_cost 判定がベースラインと並んでライブになるようにします。 
curl https://api.orcarouter.ai/api/workspace/firewall/autonomy \
  -H "Authorization: Bearer <your console access token>" \
  -H "X-Workspace-Id: <workspace>" \
  -H "Content-Type: application/json" \
  -d '{"level": "balanced"}'
Events を 1 時間監視します。実際のブロックがいまや [shadow] プレフィックスなしで現れ ます。拒否されたツール呼び出しは HTTP 400 firewall_blocked を返します；それは skip-retry であり、モデルトークンを消費しません。 それから、tight。 balanced が静かになったら、デフォルト deny に進みます。tight レベルはデフォルトで deny し、破壊的シェルおよび SSRF egress を deny し、そして PII Shield + Secrets Blocker を強制します — PII はモデルが見る前にリクエストで マスクされ、あなたのリクエスト内のシークレットはブロックされます。ブロックされた プロンプトは HTTP 400 guardrail_blocked を返し、クォータを消費せず、skip-retry です。
ステージファイアウォール（アクション）ガードレール（テキスト）あなたが証明していること
permissiveObserve；何もブロックしないflag のみ実トラフィックの形
balancedデフォルト audit；破壊的シェル denyPII を flag最悪のケースが止められる
tightデフォルト deny；シェル + fetch 形ツール（SSRF）denyPII を mask、secrets ブロック完全なゼロトラスト
PII のストリーミングに関する注意点。 tight 下では、PII Shield はモデルが見る前に リクエストで PII をマスクします — それはライブです。ストリーミングレスポンスの 出力側マスキングはまだライブではありません；出力 block はストリーミングで強制 されます（スキャナがストリームを切断します）。モデル出力のリダクトに依存するなら、 ガードレールの Test タブで、あなたのステージ/ストリームの組み合わせをまず検証して ください。ガードレールを参照。

​
5. 脱出ハッチ — ワンクリックの取り消し

すべての自律性変更は、あなたの直前の姿勢をスナップショットするひとつのトランザクション なので、Firewall → Posture（または POST /api/workspace/firewall/autonomy/undo/:audit_id）からまっすぐロールバックできます。 あるいは、単により柔らかいレベルを再適用することもできます — tight を balanced に、 または balanced を permissive に — いつでも。
取り消しは、最新の適用の監査スナップショットから復元します。取り消そうとしている 適用以降に手動でポリシー編集を行った場合、そのスナップショットはもはや最新の未使用の ものではなく、取り消しはそれらの編集をサイレントにロールアウェイするのではなく辞退します。 そうなったときは、代わりにより柔らかいレベルを再適用してください — それは常に利用 可能です。

​
6. 各動きの判定がどこから来るか

ロールアウトは、各姿勢が明示的で観察可能なメカニズムにマッピングされるため、あなたが 求めなかったものを決してブロックしません：
姿勢メカニズム結果
Observeワークスペース firewall_observe_mode オン + ガードレール flag許可 + ギャップ / マッチをログ
Shadowポリシーごとの shadow_mode実際の判定を計算、audit に格下げ、[shadow] would … とログ
Enforceshadow_mode オフ + tight/balanced 自律性deny / mask / cap_cost がライブになる
4 つの用語 — 観察モード、audit 判定、flag アクション、そして shadow_mode — は 別個のスイッチであり、強制モードに並べて ドキュメント化されています。

​
7. 次のステップ

強制モード

observe、shadow、enforce の背後にあるメカニズムマップ。

Secure Agents ベースライン

各自律性レベルが何を設定するか、そしてまずそれをシミュレートする方法。

自律エージェントを手懐ける

強制した後の次のステップ：コスト上限、異常検出、そして承認。

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

ポリシー、ルール、判定、シャドウモード、そして MCP ゲートウェイを完全に。
信頼できる go-live は、スイッチではなくロールアウトです。あなたのエージェントが何をするかを 観察し、その実トラフィックに対してポリシーをシャドウし、それから強制する — tight の前に balanced — そしてすべてのルールが、それを初めてブロックする前に本番で検証されます。