メインコンテンツへスキップ
リクエストが HTTP 400 を返し、エージェントが止まりました。コードを変更する前に、 ゲートウェイはすでに何が起きたかを伝えています：エラーコードがどのコントロールが 発火したかを名指しし、2 つのフィードのいずれかが正確なルールを名指しします。 このページは、ルックアップとトレースのフローです — コードを読み、正しいフィードを 開き、ルールを見つける。 ひとつだけ覚えるなら：セキュリティコントロールからの 400 は、あなたのプロンプトの バグではありません。ポリシーが仕事をしているのです。あなたの仕事は、どのポリシーかを 見つけ、それから呼び出しを修正するかルールを緩和するかを決めることです。

​
1. なぜ LLM リクエストがブロックされたのか？ — エラーコードから始める

ホスト型ゲートウェイ上のすべてのセキュリティブロックは、OpenAI 形式のエラーボディに マシン可読な code を伴って HTTP 400 を返します。そのコードが最初の分岐点です — どのコントロールプレーンをデバッグすべきか、どのフィードを開くべきかを教えてくれます。 
{
  "error": {
    "message": "tool \"shell.exec\" blocked by firewall: destructive shell command",
    "code": "firewall_blocked",
    "type": "invalid_request_error"
  }
}

guardrail_blocked

**ガードレール**のコンテンツルールが、リクエスト 入力またはモデル出力で発火しました。Matches フィードでトレースします。 §2を参照。

firewall_blocked

**ファイアウォール**ルールがツール呼び出しを拒否しました。 Events フィードでトレースします。 §3を参照。

firewall_approval_pending

ツール呼び出しが人間の承認のために保留されています — 拒否ではありません。 デバッグするのではなく、解決してください。 §4を参照。
3 つのコードはすべて skip-retry です：同一の呼び出しを再実行すると、同じポリシーに ルーティングされ、再びブロックされます。リトライは無駄なレイテンシです — 代わりに 入力かルールを修正してください。完全なコードテーブルは エラーコードにあります。

​
2. guardrail_blocked — Matches でルールを見つける

guardrail_blocked は、キー（またはワークスペースデフォルト）にアタッチされた コンテンツポリシーが、リクエスト入力またはモデルの出力に対して block アクションを 実行したことを意味します。ブロックメッセージはガードレールとルールを名指しし、 リクエストはクォータを消費しません — 入力ブロックはメータリングの前に発火し； 出力ブロックは事前消費されたクォータを返金します。 トレースする方法：
1

Matches フィードを開く

コンソールで、Guardrails ページの Matches タブ（GET /api/guardrail/match、 Member）へ移動します。発火したすべてのルールがここに着地します — その RuleType、 Action、Stage、そして pii: email, phone や matched 3 keyword(s) のような Detail 文字列です。
2

ブロックでフィルタする

action = block とリクエスト時刻でフィルタします。マッチした行は、ルールタイプ （pii、regex、keyword、max_chars、llm_judge、grounding、external）と、 それが input ステージで発火したか output ステージで発火したかを教えてくれます。
3

実際に何にマッチしたかを見る

デフォルトでは、フィードはルールが発火したこととその Detail メタ文字列を 記録します — マッチした部分文字列は記録しません。トリアージのために問題の 文字列をキャプチャするには、そのガードレールで Log raw content をオンにします （デフォルトはオフ、プライバシー保守的な姿勢です）。トグルは遡及しません。
誤りだと思うブロックですか？ マッチを開いて誤検知としてマークします （POST /api/guardrail/match/:id/mark-fp、Admin）。出荷前に修正を証明するには、 ルールを編集し、ガードレールエディタの Test タブでサンプルを再実行します — アップストリーム呼び出しなし、クォータなし。

​
ひとつの具体例

カスタマーの SSN を含むサポート返信を送信します。あなたの pii-shield ガードレールには、 ssn でブロックする entity_actions オーバーライドがあります： 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "ssn"],
  "entity_actions": { "ssn": "block" }
}
ゲートウェイは 400 guardrail_blocked を返します。Matches フィードは RuleType: pii、Action: block、Stage: input、Detail: pii: ssn を表示します。 修正はコード変更ではなく製品上の決定です：オーバーライドを mask に緩和する （モデルは SSN を決して見ず、呼び出しは通る）か、ブロックを維持してアップストリームで SSN を取り除きます。完全なルールタイプと PII エンティティのリファレンスについては、 ガードレールを参照してください。

​
3. firewall_blocked — Events で判定を見つける

firewall_blocked は、ファイアウォールポリシーがツール 呼び出しを拒否したことを意味します。inbound サーフェスでは 400 として表面化し； MCP ゲートウェイ経由ではツールエラー（firewall deny: <reason>）として表面化する ため、モデルはクラッシュする代わりに反応できます。エラー metadata は、理由コード、 リスク要因、スコアを運びます。 Events フィードでトレースします（GET /api/workspace/firewall/events、Developer+） — すべての評価の背後にある生のレコードです。各イベントは判定と、それが見られた サーフェスを運びます：
判定あなたのブロックにとって何を意味するか
denyルール（または default_verdict）が呼び出しをブロックしました。これがあなたの firewall_blocked です。
audit許可されたがログされた — ポリシーがシャドウモードの場合は [shadow] 「would deny」を含みます。
cap_cost実行の累積支出がルールごとのセント上限を超えました；deny に解決します。
1

Events を拒否でフィルタする

verdict=deny でフィルタし、それから tool、run_id、または session_id で フィルタして、正確な呼び出しを切り分けます。イベントはマッチしたルールとサーフェス — inbound、response、mcp、または egress — を名指しします。
2

マッチしたルールの理由を読む

理由文字列（例：destructive shell command、egress host not allowed）は、 ルールがツール名でマッチしたか、args_match 句でマッチしたか、egress 宛先で マッチしたかを教えてくれます。 判定用語集と glob と JSONPath リファレンスが マッチングを解読します。
3

Test サンドボックスで確認する

ファイアウォールの Test タブ（POST /api/workspace/firewall/test、Developer+）で 同じツール呼び出しをリプレイし、判定、マッチしたルール、理由を確認します — 何も ディスパッチされず、何もログされません。
cap_cost deny はルールの誤発火ではありません — あなたのエージェント実行が、 あなたが設定した支出上限にヒットしたのです。実行がループしている（Runs ロールアップと 異常フィードで retry_loop をチェック）か、 上限がそのタスクには本当に低すぎるかのどちらかです。単にリトライするのではなく、 意図的に上限を上げてください。

​
4. firewall_approval_pending — 拒否ではなく保留

firewall_approval_pending は、ブロックとして扱うべきでない唯一の 400 です。 pending_approval 判定がツール呼び出しを人間のために保留しました；エラーボディは 承認 id を運びます。呼び出しは失敗していません — 待機しているのです。
  1. レビュアーがそれを解決します — コンソールから（Developer+）、あるいはあなた自身の HMAC webhook コールバック経由（POST /api/v1/firewall/approvals/:id/callback）。
  2. エージェントは、エラーから得た id について GET /api/v1/firewall/approvals/:id（ゲートウェイトークン）をポーリングします。
  3. 承認されると、単回使用の X-OrcaRouter-Firewall-Approval ヘッダーとともに元の 呼び出しを再送信し、ゲートウェイはその一度だけ通します。
フル HITL ループについては ファイアウォール → 人間による承認を 参照してください。

​
5. セキュリティブロックではない？ まずキーを除外する

すべての 400 がガードレールやファイアウォールの判定ではありません。フィードを 掘り下げる前に、キーの制約を除外してください — これらはどのポリシーが走る前にも 拒否し、上記のセキュリティコードを運びません：
キーの model_limits 許可リストが、リクエストされたモデルを含んでいません。 リスト外のモデルへのリクエストは、前段で拒否されます。モデルをキーに追加するか、 許可されているものを呼び出してください。
キーに allow_ips 許可リストがあり、リクエストがその外のアドレスから来ました。 呼び出し元の IP / CIDR を追加するか、許可されたネットワークから呼び出してください。
キーの credit_limit_usd 上限が枯渇しました（0 は無制限を意味します）。上限を 上げるか、余裕のあるキーにローテートしてください。
ゲートウェイフック（evaluate、MCP ディスパッチ）は is_firewall_gateway=true の キーを必要とします。通常のリレーキーは 403 を受け取ります。それらのルート用に ファイアウォールゲートウェイスコープのキーを発行してください。

​
6. 2 分間のトリアージフロー

プロンプトまたはレスポンステキストでのブロック

コードが guardrail_blocked → Matches を開き、action=block で フィルタし、Stage + Detail を読みます。コンテンツかルールを修正し； ガードレールの Test タブで証明します。

ツール呼び出しでのブロック

コードが firewall_blocked → Events を開き、verdict=deny で フィルタし、サーフェス + 理由を読みます。呼び出しかルールを修正し；ファイア ウォールの Test タブで証明します。

呼び出しが保留されている

コードが firewall_approval_pending → 承認 id をポーリングし、承認ヘッダーと ともに再送信します。デバッグするものはありません。

上記のいずれでもない

セキュリティコードなし → キーをチェック：model_limits、allow_ips、 credit_limit_usd、またはゲートウェイスコープ欠如による 403。

​
7. 関連リファレンス

エラーコード

完全なコードテーブル — ゲートウェイが返しうるすべてのブロック、保留、拒否。

判定用語集

各ファイアウォール判定が何を意味し、いつ deny に解決するか。

Glob と JSONPath

あなたの呼び出しにマッチした tool_name_glob と args_match を解読します。

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

どのプレーンが発火したか — テキストスクリーニングかアクション統制か。
コントロールそのものについては、ガードレールと ファイアウォールを参照してください；それらが止める脅威に ついては、脅威モデルから始めてください。