メインコンテンツへスキップ
ネットワークに到達できるエージェントはデータパイプに変えることができます。 攻撃者がエージェントが読むドキュメントに指示を仕込みます — Web ページ、取得された チャンク、ツール結果 — そしてそれらの指示がエージェントを攻撃者が制御するホストへ 機密データを POST するよう、または内部サービスを探索する（SSRF）よう誘導します。 エージェントは決して「持ち出しを決定」しません；正当な指示に見えるものを実行します。 このページでは、OrcaRouter のエージェントファイアウォールとガードレールスタックが どのようにして AI データ持ち出しに対して防御できるかを説明します — エージェントのコード変更なしで。
ファイアウォールは egress をMCP ディスパッチパスまたは evaluate フック経由でゲートウェイを 通じてルーティングされた宛先に対してのみ見ます。エージェントが完全に自身のプロセス内で 実行するツールはその視界外です。エージェントのネットワーク系ツール呼び出しをゲートウェイ 経由でルーティングすれば、それらは統制されます。

​
1. 攻撃の仕組み

エージェントを通じた正規パスは 3 つのステップで実行されます：
  1. インジェクション — エージェントが埋め込まれた指示を持つ信頼されていないコンテンツを 読みます（Web ページ、取得されたドキュメント、CRM ノート）。
  2. 収集 — インジェクションされた指示がエージェントに機密素材を収集するよう指示します — API キー、データベース行、ユーザー PII — すでに持っているツールを使用して。
  3. 持ち出し — エージェントがその素材を fetch 型ツール経由で送り出すよう指示されます： http_fetch、web_search、fetch_url、または request。宛先は攻撃者が制御します。
SSRF は同じ形で内向きに向けられます：外部ホストではなく 169.254.169.254（クラウド メタデータ）、内部 Redis ポート、または別のプライベートサービスにエージェントが誘導されます。 インジェクションステップについてはプロンプトインジェクション を参照してください；このページはネットワークステップに集中します。

​
2. Egress 許可リスト — アウトバウンド宛先をロックする

最も耐久性のある防御は egress 許可リストです：エージェントが正当に到達することを 許可されるホストを列挙し、他のすべてを deny します。 egress ルールは stage: egress と egress フィールドを使用します。判定が方向性を 制御します — allow がリストされた宛先を通過させます；低い優先度の deny キャッチオールが 残りをブロックします： 
[
  {
    "priority": 10,
    "label": "Allow known API endpoints",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "allow",
    "egress": {
      "allow": [
        "api.openai.com",
        "api.anthropic.com",
        "api.orcarouter.ai"
      ]
    }
  },
  {
    "priority": 20,
    "label": "Deny all other outbound destinations",
    "stage": "egress",
    "tool_name_glob": "*",
    "verdict": "deny"
  }
]
エントリは CIDR、IP リテラル、または大文字小文字を区別しないホスト名としてマッチします。 ホスト名はベストエフォートで解決され IP/CIDR エントリに対して再チェックされるため、 DNS によって返された 169.254.169.254 などの宛先は依然として 10.0.0.0/8 CIDR deny エントリによって捕捉されます。ブロックされた呼び出しはエラーコード firewall_blocked とともに HTTP 400 を返します。 明示的な許可リストなしに既知の悪い範囲を deny するには、クラウドメタデータエンドポイント （169.254.169.254）と RFC-1918 プライベート範囲（10.0.0.0/8、172.16.0.0/12、 192.168.0.0/16）をリストしたターゲットの egress deny ルールを書きます。deny ルールが 最初に評価されるように、より低い優先度番号で許可リストをその上に重ねます。

​
3. 名前層で fetch 型ツールをブロックする

egress 宛先が評価される前でも、ケイパビリティ全体を削除できます。tight 自律性レベルは http_fetch、web_search、fetch_url、request を SSRF と持ち出しのバックストップとして ツール名グロブで deny します。エージェントがそれらのツールを必要としない場合、tight は ひとつのステップで攻撃表面を削除します： 
POST /api/workspace/firewall/autonomy
{ "level": "tight" }
完全な tight 姿勢を採用せずに fetch ツールを deny するには、inbound サーフェスの deny ルールを書きます。inbound はモデルが選択できる前にツールをブロックします — エージェントはツールリストでそのケイパビリティを決して受け取りません： 
{
  "priority": 5,
  "label": "Deny fetch-shaped tools",
  "stage": "inbound",
  "tool_name_glob": "http_fetch",
  "verdict": "deny"
}
エージェントスタックが使用する各 fetch 型ツール名に対して繰り返します。

​
4. Secrets Blocker ガードレール — プロンプトでクレデンシャルを止める

Secrets Blocker ガードレールは入力ステージで実行され、リクエストがゲートウェイを 離れる前に AWS スタイルのアクセスキー、OpenAI キー、Anthropic キー、GitHub トークン、 および同様のクレデンシャルパターンのプロンプトをスキャンします。シークレットが検出された 場合、リクエストはブロックされます — クレデンシャルはモデルに到達せず、ツール呼び出しにも 現れません。 Guardrails パネルから、または tight 自律性レベルの一部として有効にします。 ファイアウォールの egress ルールから独立しています。
脅威それを止めるレイヤー
プロンプトに API キーが含まれるSecrets Blocker（入力ガードレール）
エージェントが攻撃者ホストへの fetch ツールを呼び出すEgress allow/deny ルール
Fetch 型ツールがモデルにアドバタイズされるInbound deny ルールまたは tight 自律性
エージェントがクラウドメタデータまたは RFC-1918 に到達それらの CIDR をリストする Egress deny ルール

​
5. Shadow mode でロールアウトする

今日エージェントが正当に到達するホストがわからない場合、強制する前に shadow mode で始めます：
  1. 意図した許可リストで egress ルールを作成し、ポリシーで shadow_mode: true を設定します。
  2. Events フィードを見ます — ブロックされるだろう呼び出しが宛先とともに [shadow] would deny として現れます。
  3. 攻撃者到達可能な宛先のみが deny されるまで allow リストを調整し、その後 shadow mode を 無効にして強制を開始します。
Shadow mode がオンの間はトラフィックはブロックされません。

​
6. 次のステップ

ファイアウォールルールリファレンス

完全なマッチング言語 — egress リスト、CIDR、引数句、すべての判定。

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

ポリシー、サーフェス、自律性レベル、可観測性。

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

エージェントを持ち出しに誘導するインジェクションステップ。

MCP ツールポイズニング

fetch 型ケイパビリティを登録する悪意のある MCP ツール。