メインコンテンツへスキップ
OrcaRouter はすべてのリクエストに固定された順序で 4 つのレイヤーを適用します。 各レイヤーは独立しており、ワークスペーススコープで、コード変更なしに API キーに アタッチされます。このページでは、ひとつのリクエストを 4 つのレイヤーすべてを 通じて順番にウォークし、解決順序とフェイルオープン/フェイルクローズの動作を説明します。 より広範な入門については OrcaRouter による AI エージェントのセキュリティ を参照してください。

​
1. レイヤー 1 — スコープされた API キー

キーは最初のゲートです。コンテンツが検査されたり、モデルが呼び出される前に、 ゲートウェイは呼び出しキーを解決し、リクエストが許可されるかどうかを決定します。 キーが持つもの：
  • model_limits — キーが呼び出すことができるモデルのセット。リスト外のモデルへの リクエストは即座に拒否されます。
  • allow_ips — オプションの IP 許可リスト。リスト外のソースからのリクエストは 拒否されます。
  • credit_limit_usd — ハードな支出上限。キーが上限を超えるリクエストは拒否されます。
  • expiry — ハードな有効期限日。期限切れのキーは拒否されます。
  • environment — デプロイメント環境ごとにキーを整理・識別するためのタグ （production、staging、dev、…）。
  • guardrail_id — このキーにバインドされるガードレールポリシー（レイヤー 2 と レイヤー 4 を参照）。
  • firewall_policy_id — このキーにバインドされるファイアウォールポリシー （レイヤー 3 を参照）。
  • is_firewall_gateway — キーをファイアウォールゲートウェイスコープトークンとして フラグします；evaluate および MCP ゲートウェイルートに必要です。
キー検証に失敗したリクエストはモデルに到達しません — そしてメータリングもされません。 設定場所： コンソール → API Keys、またはトークン API。作成または編集には Developer+ が必要；is_firewall_gateway とプレーンテキストキーの読み取りには Admin が必要。 完全なキーモデルについては スコープ、キー、ポリシー、ワークスペース を参照してください。

​
2. レイヤー 2 — 入力ガードレール

キーが検証されると、ゲートウェイはバインドされたガードレールの入力ステージルールを リクエストテキストに対して実行します — アップストリームのモデル呼び出しの前に。 何を見るか： 送信された発呼者のメッセージ。（レジストリプロンプトからインジェクション されたプロンプトは後でルーティングステージで追加されます；入力ルールはそれを見ません。） 利用可能なルールタイプ： keyword、regex、pii、max_chars、external、 llm_judge、grounding。 ルールが生成できるアクション：
アクション何が起きるか
blockリクエストが拒否されます — HTTP 400 guardrail_blocked。クォータは請求されません。skip-retry とマークされます。
maskマッチがリダクトされます（例：jane@acme.com → [EMAIL]）。サニタイズされたテキストがモデルに継続します。
flagマッチが記録されます；トラフィックは変更されません。
このステージでの block はモデルが決して呼び出されないことを意味します。コスト：ゼロ。 発呼者はガードレールと発火したルールを示す構造化されたエラーを見ます。 設定場所： コンソール → Guardrails、またはガードレール API。作成または変更には Developer+ が必要。完全なルールリファレンスについては ガードレールを参照してください。

​
3. レイヤー 3 — モデルの実行

キーが有効で入力ガードレールが通過すると、ゲートウェイはリクエストをアップストリーム モデルに転送します。これは設定可能な強制がない唯一のレイヤーです — 単純にモデルが その仕事をしているだけです。 ファイアウォールはモデルが生成するアクション（レイヤー 3 → 以下のレイヤー 4）に 対して動作し、モデル自体に対してではありません。ルーティング、フォールバック、 ロードバランシングはここで透過的に行われます。

​
4. レイヤー 4 — エージェントファイアウォール（ツール呼び出しと egress）

モデルが応答した後 — またはツール呼び出しが発行されるのに合わせてインラインで — エージェントファイアウォールはモデルがリクエストするすべてのアクションを判断します。 4 つの強制サーフェス：
サーフェスファイアウォールが見るもの
inboundエージェントがモデルにアドバタイズするツール定義。モデルが選択する前に危険なツールをブロック。
responseモデルがその返信で発行する tool_calls。
mcpファイアウォール MCP ゲートウェイまたは evaluate フック経由でディスパッチされる tools/call。
egressツールが報告するアウトバウンドネットワーク宛先（ホスト / IP / CIDR） — SSRF とデータ持ち出しのサーフェス。
ルール（またはデフォルト）が生成できる判定：
判定何をするか
allow呼び出しが通過します。ログされます。
audit呼び出しが通過します；レビュー用に記録されます。デフォルトの default_verdict です。
deny呼び出しがブロックされます — inbound サーフェスでは HTTP 400 firewall_blocked；mcp ではツールエラー。
sanitizeマッチした部分文字列がツール引数からリダクトされます；クリーンな呼び出しが転送されます。inbound（まだ引数がない）では deny にエスカレートします。
pending_approval呼び出しが保留されます；帯域外のレビュアーが承認または拒否します；エージェントが単回使用の承認トークンで再送信します。
cap_costエージェント実行の累積支出がルールごとのセント上限を超えたら deny します。
inbound サーフェスでの deny はモデルトークンを消費しません — ブロックはアップストリーム 呼び出しの前に発火します。pending_approval 保留はクライアントがポーリングする 承認 id とともに HTTP 400 firewall_approval_pending を返します。 設定場所： コンソール → Firewall、またはファイアウォール API。ポリシーとルールの 作成または変更には Developer+ が必要。完全なルール言語については ファイアウォールと ファイアウォールルールを参照してください。

​
5. レイヤー 5 — 出力ガードレール

モデルが応答した後（そして、ツール呼び出しサイクルが完了した後）、ゲートウェイは バインドされたガードレールの出力ステージルールを、発呼者に到達する前にレスポンス テキストに対して実行します。 レイヤー 2 と同じルールタイプとアクションが適用されます。出力 block は HTTP 400 guardrail_blocked を返し、事前消費されたクォータを返金します — 発呼者は何も支払いません。
ストリーミングと出力マスキング。 block アクションはストリーミングと非ストリーミング の両方のレスポンスで強制されます — ストリームでは、スキャナーが途中で切り取り、 置換メッセージを発行します。出力に対する mask アクションは現在、非ストリーミング レスポンスにのみ適用されます；ストリーミングレスポンスでは元のチャンクがマスクされずに 通過します。依存する前に、ガードレールサンドボックスでステージ/ストリームの組み合わせを 検証してください。

​
6. レイヤー 6 — 監査

すべてのマッチ、判定、承認決定は監査証跡に書き込まれ、それを引き起こしたエージェント 実行とセッションに関連付けられます。これは独立した強制ステップではありません — レイヤー 2〜5 と並行して実行されます — しかし他のレイヤーを説明責任あるものにする レイヤーです。 ログされるもの：
  • ガードレールマッチ：ルールタイプ、アクション、ステージ、詳細文字列、および （Log raw content が有効な場合）マッチした部分文字列。
  • ファイアウォールイベント：サーフェス、ツール名、判定、マッチしたルール、 理由コード、リスク要因、および呼び出しが属する実行/セッション。
  • 承認決定：誰が承認または拒否したか、いつ、そして保留と決定の間に基礎となる ルールが変更されたかどうか。
  • ポリシー変更：すべての作成、更新、削除、自律性レベル変更がバージョン付きの 監査行を書き込みます。
確認場所： コンソール → Guardrails → Matches；コンソール → Firewall → Events、 Runs & Sessions、Audit。ガードレールの Matches フィードはすべてのワークスペース メンバーに開放されています；ファイアウォールの Events と Runs & Sessions フィードには Developer+ が必要です。

​
7. サマリーテーブル

レイヤー何を制御するか何を見るかヒット時の結果設定場所
1. スコープキーアイデンティティ、モデルアクセス、支出、IP、有効期限リクエストの認証トークン何も実行される前に HTTP 4xx；メータリングなしコンソール → API Keys（Developer+）
2. 入力ガードレールリクエストテキストコンテンツ発呼者のメッセージブロック（HTTP 400 guardrail_blocked、請求なし）、mask、または flagコンソール → Guardrails（Developer+）
3. モデル———ルーティング / チャネル設定
4. エージェントファイアウォールツール呼び出し、MCP ディスパッチ、egressツール名、引数、宛先allow / audit / deny / sanitize / pending_approval / cap_costコンソール → Firewall（Developer+）
5. 出力ガードレールレスポンステキストコンテンツモデルの返信ブロック（HTTP 400、クォータ返金）、mask、または flagコンソール → Guardrails（Developer+）
6. 監査帰属と証跡上記すべて不変のログエントリコンソール → Matches（メンバー） / Events & Runs（Developer+）

​
8. ポリシー解決順序

すべてのリクエストについて、アクティブなガードレールとファイアウォールポリシーは 独立して解決されます：
  1. キーアタッチメント — キーが明示的な guardrail_id または firewall_policy_id を持ち、そのポリシーが存在し有効な場合、それが適用されます。
  2. ワークスペースデフォルト — キーにアタッチメントがない場合、ワークスペースの 有効な is_default ガードレールまたはポリシーが適用されます。
  3. どちらもなし — 強制なし。リクエストは機能を一度も有効化していない ワークスペースとバイト単位で同一です。
アタッチされたポリシーが無効のときに 2 つのプレーンが異なります：無効または 削除されたガードレールアタッチメントはそのキーにガードレールなしを意味します （フォールバックなし）、一方、無効なファイアウォールアタッチメントは ワークスペースのデフォルトファイアウォールポリシーにフォールバックします。 ワークスペースごとに最大ひとつのガードレールとひとつのファイアウォールポリシーが デフォルトになれます。新しいデフォルトをプロモートすると、同じトランザクション内で 古いものが降格されます。

​
9. フェイルオープンとフェイルクローズ

2 つの動作 — 異なるケースに適用されます。フェイルオープン（一時的エラー）： ポリシー解決が一時的エラーに遭遇した場合 — データベースの不調、外部ベンダーへの途中でのネットワーク障害 — ゲートウェイは トラフィックを停止するのではなく強制なしに劣化します。安全性は劣化しますが、 可用性は維持されます。見逃されたチェックがポリシーにとって許容できない場合は、 external または llm_judge ルールで fail_open: false を設定してください。フェイルクローズ（曖昧なケース）： 強制しないことがルールを無効にしてしまう 場合、エンジンはフェイルクローズします：解決不可能な宛先を持つ egress レポートは deny されます；到達不能な承認ストアは通過させるのではなく呼び出しを保留します； 所有権を解決できないスキルはブロックされます。ハッピーパスでは可用性が維持されます； 重要なエッジケースで安全性がサイレントにスキップされることはありません。
完全な決定ツリーについては強制モードを、 リレーパスのメカニクスについては OrcaRouter がリクエストをどのように検査するか を参照してください。

​
10. 詳細解説

ガードレール

完全なルールリファレンス — タイプ、アクション、PII エンティティ、LLM judge、 グラウンディング、テストサンドボックス。

ファイアウォール

ポリシーモデル、判定、サーフェス、シャドウモード、HITL 承認、異常検出。

ファイアウォールルール

ルールマッチング言語 — ツールグロブ、引数句、egress リスト、サニタイザ。

ガードレール vs. ファイアウォール

どのレイヤーがどの脅威を捕捉するか — そして両方が必要なとき。

スコープ、キー、ポリシー

完全なキーモデル：キーが持つものとポリシーの解決方法。

強制モード

フェイルオープン vs. フェイルクローズ — 完全な決定ツリー。
OrcaRouter を通じるすべての呼び出しは 4 つの強制レイヤーを順番に通過します — キー検証、入力スクリーニング、ファイアウォール判断、出力スクリーニング — そして すべての完全な監査証跡がそれら全体に書き込まれます。