メインコンテンツへスキップ
エージェントをユーザーの前に置く日は、ジェイルブレイクがコンテンツポリシーをまっすぐ 通り抜けることや、統制し忘れたツールが最初の run で発火することを知るのに最悪の日です。 ローンチ前のレッドチームは、それらの驚きを、出荷前に読める数値に変えます — そして OrcaRouter はそれを生み出す 3 つの方法を提供します。すべて、あなたのエージェントコードに 触れることなく、意図しなかった単一のライブリクエストを送ることもなく。 このレシピはドライランパスです：既知の攻撃に対してポリシーを測定し、自分のトラフィックに 対してそれをシャドウし、コミットする前によりタイトな姿勢をシミュレートします。
ここにあるすべては読み取り専用かサンドボックスです — ユーザーに見えるブロックなし、 本番トラフィックへの影響なし。（キーワード、正規表現、PII ルールは完全にローカルで 実行されます；llm_judge ルールは依然として設定されたモデルを呼び出すため、judge ポリシーに対する eval はその呼び出しを行います。）要点は、あなたの条件で、ローンチ 前に物事を壊すことです。

​
1. ローンチ前に AI エージェントをレッドチームする方法

ローンチ前のレッドチームは 3 つの質問に答え、OrcaRouter にはそれぞれに 1 つのツールが あります：

私のガードレールは攻撃を捕捉するか？

ガードレールの Eval ハーネスをバンドルされた敵対的コーパスに対して実行し、 precision / recall / F1 を読み返します。

私のファイアウォールは何を壊すか？

シャドウモードをオンにして、どの実際のツール呼び出しが denyされるかを — まだ どれも deny せずに — 監視します。

よりタイトな姿勢は安全か？

自律性レベルをシミュレートして、適用前に、あなたのトラフィックに対してそれが 何を変えるかを正確にプレビューします。
最初はあなたのガードレール（テキストプレーン）をテストし ます；2 番目と 3 番目はあなたのファイアウォール（アクション プレーン）をテストします。実際のローンチチェックリストは 3 つすべてを実行します。

​
2. 敵対的コーパスに対してガードレールをスコアリングする

コンテンツポリシーが攻撃者との接触を生き延びるかを知る最速の道は、既知の攻撃のコーパスを それに投げつけてスコアを読むことです。ガードレールエディタの Eval タブはまさにそれを 行います：コーパス内のすべてのサンプルをあなたの現在のポリシーを通して再生し、判定を 各サンプルの期待される結果と比較します — コーパスをローカルであなたのルールに対して 再生し、決してライブトラフィックに対してではなく。 OrcaRouter は、あなたが自分のものを調達しなくて済むよう、バンドルされたレッドチーム コーパスを出荷しています。その中には：
コーパスそれが何か
advbench_harmful_behaviors典型的な敵対的サフィックスのターゲットセット — すべての行はガードレールがブロックすべき安全でないリクエスト。
anthropic_hh_redteamアシスタントに対する実際のマルチターンの人間レッドチーム書き起こし。
deepset_prompt_injectionsラベル付けされたプロンプトインジェクション vs 良性リクエスト — 入力ステージブロックのための precision/recall ベースライン。
databricks_dolly_benign純粋な良性ベースライン：過度に厳格なポリシーはこれらをひとつもブロックすべきではありません。
常に攻撃コーパスを良性コーパスとペアにしてください。攻撃の 100% をブロックするが databricks_dolly_benign もブロックするポリシーは安全ではありません — 使い物に なりません。良性の run があなたの誤検出予算です。
バンドルされた deepset_prompt_injections コーパスに対して eval を実行します： 
curl https://api.orcarouter.ai/api/guardrail/123/eval \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{ "corpus_name": "deepset_prompt_injections" }'
/api/guardrail/* ルートは、sk-orca-... リレーキーではなく、あなたのコンソール セッション / アクセストークンを使います — そしてそれらは X-Workspace-Id 経由で ワークスペーススコープされます。実際には、これをコンソールの Eval タブから実行する ことになります；curl は形を示すためにここにあります。eval の実行は任意の Member に 開放されています。
run は、期待されるアクションに対して計算された検出メトリクスを報告します：
  • TP / FP / FN / TN — 真/偽の陽性と陰性、ここで「偽陽性」には、攻撃を間違った アクションクラスで捕捉すること（例：ブロックを期待したのにマスキング）が含まれます。
  • Precision / Recall / F1 — 見出しの数値。低い recall は攻撃がすり抜けることを、 低い precision は良性トラフィックをブロックしていることを意味します。
run を開いて失敗をサンプルごとに検査し、ルールや judge ルーブリックをチューニングし、 スコアが保たれるまで再実行します。カスタムコーパスも同じように機能します — あなた自身の JSONL をアップロードして（Developer+）、あなたの製品が直面する正確な攻撃の形に対して テストします。
プロンプトインジェクション防御がどこに存在するか。 バンドルされた Prompt-Injection Basics プリセットは、flag アクションのキーワードルールです — ユーザーをブロックせずに、 一般的なジェイルブレイク句を表面化します。どのキーワードリストも捕捉しない意味論的な インジェクション意図には、llm_judge ルールを追加し、それを同じようにレッドチームします： deepset_prompt_injections と anthropic_hh_redteam に対して eval し、F1 を読みます。 ガードレールリファレンスを参照。

​
3. 実トラフィックに対してファイアウォールをシャドウモードにする

ガードレール eval は、固定コーパスに対してテキストをテストします。対照的にあなたの ファイアウォールは、エージェントが実際に何をするかの乱雑な現実に対してテストされる 必要があります — そしてローンチ前にそれを行う最も安全な道はシャドウモードです。 シャドウモードは、ファイアウォールにすべてのツール呼び出しを本番と全く同様に評価・ログ させるが、すべての強制判定を audit に格下げするポリシーごとのフラグです。deny は、 理由に [shadow] would … が前置された audit 行になります。何もブロックされません。何も 壊れません。しかし Events フィードは、いまやあなたのポリシーが拒否したはずの 呼び出しの正確なリストを示します。 これがファイアウォールのレッドチームです：あなたの最も厳格な意図したポリシーを作成し、 シャドウモードをオンにし、現実的なローンチリハーサルでエージェントを実行し、それから [shadow] would … イベントを読みます。
コンソール（Developer+）で強制ポリシーを構築します — ローンチのドライランには、 default_verdict を audit に設定し、出荷予定の deny ルールを追加します。 シャドウモードをオンに切り替えます。これでポリシー全体が、強制せずにログします。
シャドウされたポリシーがアタッチされたキーで、ゲートウェイに対して実際のエージェント フローを実行します。すべてのツール呼び出し — inbound、response、MCP ディスパッチ、 egress — が評価・ログされます。
Firewall → Events（Developer+）を開き、[shadow] would … の理由でフィルタ します。それぞれが、あなたのポリシーが本番で deny したはずの呼び出しです。すべての エントリが denyしたい呼び出しであること — そして正当なものがリストにないこと — を 確認します。
would-block リストがクリーンになったら、シャドウモードをオフにします。次にマッチする 呼び出しが本物で強制されます — 他の変更なし。
正しさだけでなくカバレッジのために、シャドウモードを観察モード（ワークスペース設定）と ペアにします。観察モードは、どのポリシーにも解決されないすべてのツール呼び出しを ギャップとしてログし、Discovered tools ビューを満たします — つまり、間違えたルール だけでなく、ルールを書き忘れたツールも捕捉します。 強制モードを参照。

​
4. コミットする前によりタイトな姿勢をシミュレートする

3 番目のレッドチームの動きは最も安価です：より厳格な 自律性レベルを適用する前に、それを シミュレートします。シミュレータは、tight（または任意のレベル）を適用することが、 あなたのワークスペースの最近のトラフィックに対して何を変えるか — いくつの呼び出しが deny に切り替わるか — を、単一のポリシー行も書き込まずにプレビューします。 
curl "https://api.orcarouter.ai/api/workspace/firewall/simulate?level=tight" \
  -H "Authorization: Bearer <your-session-token>" \
  -H "X-Workspace-Id: <workspace-id>"
シミュレータの読み取りは任意の Member に開放されています。それを使って、ローンチ前に 「私のエージェントは tight の準備ができているか？」に答えます：プレビューが、あなたの エージェントが依存する呼び出しへの拒否の壁を示すなら、go-live の後のインシデントでは なく、go-live の前に和らげるべきルールがあります。
シミュレートはプレビューのみです — 決してあなたのポリシーを変更しません。自律性レベルの 適用は別個の Developer+ アクションであり、ライブの結果がそれでも驚かせる場合の ワンクリックの取り消しを持つひとつのトランザクションです。

​
5. ローンチ前レッドチームチェックリスト

3 つのパスを組み合わせれば、ローンチゲートが得られます：
パスツールグリーンの条件
コンテンツポリシーガードレール Eval vs 攻撃 + 良性コーパス攻撃で高 recall、良性でブロックなし
アクションポリシーファイアウォール シャドウモード vs リハーサルトラフィックすべての [shadow] would … が意図的
カバレッジ観察モード + Discovered tools驚くツールがカバレッジギャップに座っていない
姿勢ターゲット自律性レベルを シミュレートプレビューが期待どおり
4 つすべてをグリーンで実行し、それから強制します：シャドウモードをオフにし、自律性レベルを 適用します。すべてのバインディングがゲートウェイ内のキーに存在するため、ドライランから ライブへの移行はデプロイではなく設定変更です — あなたのエージェントは以前と全く同様に https://api.orcarouter.ai/v1/... を呼び続けます。
出力ステージのマスキングとライブのレスポンススキャンはまだ成熟途上です — eval の run は ルールのロジックをサンドボックスで証明しますが、本番で依存する前に、あなたの具体的な ステージとストリーミングの組み合わせをガードレールの注記に 対して確認してください。

​
6. 次のステップ

強制モード

Observe → shadow → enforce、このレシピがリハーサルする安全なロールアウト。

Secure Agents ベースライン

各自律性レベルが何を設定するか — そして simulate がそれをどうプレビューするか。

プロンプトインジェクション

あなたのガードレール eval がスコアリングしている脅威。

ライブにする

レッドチームが通った後の本番カットオーバー。
各パスの背後にある完全なエンジンについては、 ガードレールとファイアウォールの リファレンス、そして関連する脅威を参照してください： ジェイルブレイクと 危険なツール呼び出し。