ガードレール vs. エージェントファイアウォール

短い答え：ガードレールはテキストを統制し、ファイアウォールはアクションを統制します。 それらは補完的です — ひとつのリクエストが両方を流れます — そして両方を一緒に設定する最速の方法は自律性レベルです。このページの残りは、特定の脅威がどのレイヤーに属するかを知る必要がある場合のためです。

必要なロール。 すべてのワークスペースメンバーはポリシーとガードレールの Matches フィードを読み取れます；ファイアウォールの Events フィードには Developer ロールが必要です。ガードレールまたはファイアウォールポリシーの作成または編集にも Developer 以上が必要です。

1. ひと言の区別

レイヤー	統制するもの	見るもの
ガードレール	テキスト — モデルが読み書きするもの	プロンプトコンテンツ、レスポンスコンテンツ
エージェントファイアウォール	アクション — エージェントが行うこと	ツール呼び出し、MCP ディスパッチ、アウトバウンドネットワーク宛先

ガードレールはアップストリーム呼び出しの前（プロンプトに対して）と後（レスポンスに対して）に発火します。ファイアウォールはモデルが発行するまたはエージェントが発行するすべてのツール呼び出しに発火します — そのターンを処理したモデルまたはプロバイダに関わらず。

2. 並べて比較

ディメンション	ガードレール	エージェントファイアウォール
統制するもの	プロンプトテキストとモデルレスポンステキスト	ツール呼び出し、MCP ディスパッチ、egress 宛先、エージェントコスト
見るもの	ユーザーメッセージ、システムプロンプト、モデルの返信	ツール名、呼び出し引数、モデルが発行するツール呼び出し、アウトバウンドホスト/IP
アタッチ方法	API キーの `guardrail_id`	API キーの `firewall_policy_id`
ルールタイプ	`keyword`、`regex`、`pii`、`max_chars`、`external`、`llm_judge`、`grounding`	ツール名グロブ + 引数句 + egress スコープ + スキル所有権
脅威の例	プロンプト内の PII、レスポンス内の API シークレット、jailbreak、トピック外出力、過大なコンテキスト	危険なツール呼び出し、SSRF、データ持ち出し、暴走エージェントコストループ、未承認の MCP サーバー
判定 / アクション	`block`（HTTP 400 `guardrail_blocked`）、`mask`、`flag`	`allow`、`audit`、`deny`（HTTP 400 `firewall_blocked`）、`sanitize`、`pending_approval`、`cap_cost`
発火タイミング	入力ステージ：モデル呼び出しの前；出力ステージ：モデルが返信した後	モデルが発行するまたはエージェントが発行するすべてのツール呼び出しで
Shadow / observe mode	なし — ガードレールは発火するかしないか	はい — shadow mode は強制判定を `audit` に格下げして安全なロールアウト

3. 脅威 → どのレイヤー

新しいセキュリティ要件を適切なコントロールにルーティングするには、このテーブルを使用します：

脅威	使用するもの
ユーザーメッセージ内の PII	ガードレール — 入力 `pii` ルール（`mask` / `block`）
モデルのレスポンス内のシークレット	ガードレール — 出力シークレットルール
危険なツール呼び出し（`shell.exec rm -rf /`）	ファイアウォール — ツールグロブ + 引数句で `deny`
SSRF / アウトバウンド URL 経由のデータ持ち出し	ファイアウォール — egress 許可/拒否リスト
信頼されていないコンテンツからのプロンプトインジェクション	両方 — 入力ガードレール + ファイアウォール許可リスト
ツール引数内のシークレット	ファイアウォール `sanitize` + ガードレールシークレットルール
Jailbreak / ポリシーバイパス	ガードレール — `llm_judge` / keyword / regex
過大なプロンプトまたはトークンコスト	ガードレール — `max_chars` ルール
暴走エージェント支出（コストループ）	ファイアウォール — `cap_cost` 判定
未承認の MCP サーバー	ファイアウォール — MCP サーフェス deny / `pending_approval`
ツール結果からの機密データ	ガードレール — レスポンスの出力ルール

各ペアリングの詳細な「理由」は Threats の詳細ページにあります。

4. 両方を使用する — 自律性レベルで一緒に設定する

ガードレールとファイアウォールは競合ではなく、構成するように設計されています。ひとつのリクエストが両方のプレーンを通過します：

入力ガードレールが実行されます — プロンプトテキストがスクリーニングされ、オプションでマスクされます。
モデル呼び出し — （おそらくサニタイズされた）プロンプトがアップストリームモデルに到達します。
ファイアウォール — モデルが発行するすべてのツール呼び出しが評価されます。
出力ガードレールが実行されます — モデルのレスポンステキストがスクリーニングされます。

両方を一度に設定する最速の方法は自律性レベルです — ワークスペース全体のファイアウォールポリシーとガードレールポリシーをアトミックに書く単一の設定で、ワンクリック取り消しが可能です：

自律性レベル	ファイアウォール姿勢	ガードレール姿勢
`tight`	デフォルト deny；破壊的シェル + SSRF egress をブロック	PII Shield + Secrets Blocker をオン
`balanced`	デフォルト audit；破壊的シェルを deny	PII Shield audit-only（PII をフラグ）
`permissive`	強制ルールなし；observe mode をオン	強制なし

ファイアウォールコンソールから自律性レベルを適用します（POST /api/workspace/firewall/autonomy、 Developer+）、その後各プレーンを独立してチューニングします。

5. まとめ

ガードレールはテキストを所有し、ファイアウォールはアクションを所有します — 両方を実行し、自律性レベルで接続し、エージェントの実際のトラフィックを見ることができたら各プレーンを独立して強化します。