メインコンテンツへスキップ
ネットワークに到達できるエージェントは、データパイプに変えられ得ます。インジェクション された指示が、エージェントに、既に持っているツールでシークレット、行、あるいは PII を 集めて攻撃者ホストに POST するよう告げます — あるいは内部サービスを探ります（SSRF）。 エージェントは決して持ち出そうと「決断」しません；それにとって正当な指示に見えるものを 実行するだけです。 このレシピは、ループをエンドツーエンドで閉じる 3 つのコントロールを配線します — アウトバウンド呼び出しの行き先をロックする egress 許可リスト、クレデンシャルが モデルに届く前に止める Secrets Blocker ガードレール、そしてモデルが発する ツール呼び出しからシークレットを取り除く引数サニタイザ。そのすべてがゲートウェイに 存在するため、エージェントコードへの変更ゼロでコンソールから一度設定します。完全な 攻撃の解剖については、 ネットワーク越しのデータ持ち出しを読んで ください；このページは構築ステップです。
ここにあるすべてはあなたのワークスペースにバインドされ、コンソールから設定されます。 あなたのエージェントは同じ sk-orca-... キーで https://api.orcarouter.ai/v1/... を 呼び続けます — 変わるのはゲートウェイ内のポリシーだけです。設定アクションは各ステップで 示されるロールを必要とします；リレー呼び出しはスコープキーを使います。ファイアウォールは ゲートウェイ経由でルーティングされた宛先（MCP ディスパッチパスまたは evaluate フック）に ついてのみ egress を見ます — ネットワークにバインドされたツール呼び出しをそこ経由で ルーティングすれば、それらは統制されます。

​
1. AI データ持ち出しを防ぐ 3 つのレイヤー

各レイヤーは、リクエストライフサイクルの異なるポイントで攻撃を捕捉します。3 つすべてを スタックします — それらは独立しており補完的です。

プロンプト内のクレデンシャル

リクエストに貼り付けられた（または引き込まれた）シークレットは、どのモデルも見る 前に、入力ステージで Secrets Blocker ガードレールによって捕捉されます。

ツール引数内のシークレット

クレデンシャルを運ぶツール呼び出しを発するモデルは、マッチした引数をリダクトする sanitize ファイアウォールルールによってクリーニングされます。

アウトバウンド宛先

実際のネットワークステップは egress 許可リストによって境界づけられます — 列挙されたホストのみが通過し、それ以外はすべて deny されます。
このレシピは両方のプレーンを使います：リクエスト内のテキストには ガードレール、アクションとネットワークには ファイアウォール。境界がどこにあるかは ガードレール vs ファイアウォールを 参照してください。

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

最初にロックすべきはクレデンシャル自体です。Secrets & API-Key Blocker ガードレールは 入力ステージで実行され、リクエストがゲートウェイを離れる前に、クレデンシャルの パターン — AWS スタイルのアクセスキー、OpenAI キー、JWT、および類似のトークン — を リクエストでスキャンします。マッチするとリクエストはブロックされます：クレデンシャルは 決してモデルに到達せず、決してツール呼び出しに着地しません。 コンソールで Guardrails → New guardrail を開き（Developer ロール；読み取りと Test サンドボックスは任意のメンバーに開放）、exfil-shield と名付け、テンプレート ライブラリ（カテゴリ secrets）から Secrets & API-Key Blocker プリセットを 適用します。プリセットは、クレデンシャルの形ごとに 1 つずつ、3 つの input ステージの 正規表現 block ルールを播種します — AWS アクセスキー、OpenAI スタイルのキー、 GitHub トークン： 
[
  { "type": "regex", "stage": "input", "action": "block", "pattern": "AKIA[0-9A-Z]{16}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "sk-[A-Za-z0-9]{20,}" },
  { "type": "regex", "stage": "input", "action": "block", "pattern": "ghp_[A-Za-z0-9]{36}" }
]
カバレッジを拡張するには、組み込みエンティティに対する pii ルールを追加します — ディテクタセットは email、phone、credit_card、ssn、ip、iban、mac_address、 api_key_openai、aws_access_key、jwt、bitcoin_address をカバーします。 entity_actions でエンティティごとに mask（[EMAIL] のような型付きタグへリダクト） または block を選びます。入力ステージのマスキングはライブです；モデルが見る前に リクエストを書き換えます。
ブロックされたリクエストは HTTP 400 guardrail_blocked を返し、クォータを 消費せず（入力ステージのブロックはメータリングの前に発火します）、skip-retry と マークされます。Test タブで証明してください — サンプルの AWS キーを貼り付け、 input ステージを選び、判定を確認してから、キーをアタッチします。

​
3. ツール呼び出し引数からシークレットをサニタイズする

ガードレールはプロンプトをスクリーニングします；それはモデルが発するツール呼び出しを 見ません。モデルがクレデンシャルを引数に運ぶ tool_call を生成するとき、ファイア ウォールの sanitize ルールがそれを捕捉します。sanitize はツール呼び出し引数から マッチした部分文字列をリダクトし、クリーニングされた呼び出しを転送します — ツールは 実行されますが、シークレットは取り除かれています。 Firewall → Policies → New policy（Developer ロール）で exfil-firewall と 名付け、response サーフェス — モデルがその返信で発する tool_calls — に sanitize ルールを追加します： 
{
  "priority": 10,
  "label": "Redact secrets from tool args",
  "stage": "response",
  "tool_name_glob": "*",
  "verdict": "sanitize",
  "sanitize": {
    "presets": ["aws_access_key", "openai_key"],
    "custom": ["sk-[A-Za-z0-9]{20,}"]
  }
}
sanitize はツール呼び出しの引数のみをリダクトします — ツールが返すコンテンツは 決してリダクトしません。これはアウトバウンドの呼び出しの形に対する防御であり、 インバウンドのツール結果に対するものではありません。inbound サーフェス（まだ呼び出し 時の引数がない）では、sanitize 判定は deny にエスカレートします。完全なマッチング 言語はファイアウォールルールを参照して ください。

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

最も耐久性のある防御はネットワーク境界そのものです：あなたのエージェントが正当に 到達してよいホストを列挙し、それ以外をすべて deny します。egress ルールは stage: egress と egress フィールドを使います；判定が極性を設定します — allow は リストされた宛先を通し、より低優先度の deny キャッチオールが残りをブロックします。 同じ exfil-firewall ポリシーに次のルールを追加します： 
[
  {
    "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 リテラル、または大文字小文字を区別しないホスト名としてマッチします。 明示的な許可リストなしに内部サービスへの SSRF を止めるには、クラウドメタデータ エンドポイント（169.254.169.254）と RFC-1918 プライベート範囲（10.0.0.0/8、 172.16.0.0/12、192.168.0.0/16）をリストする egress deny ルールを自分で作成 します。拒否された呼び出しは HTTP 400 firewall_blocked を返します。
CIDR egress ルールを出荷するプリセットはありません — host/CIDR の allow と deny の エントリは自分で作成します。tight 自律性レベルが隣接する高速パスです： fetch 形のツール名（http_fetch、web_search、fetch_url、request）を完全に deny し、宛先が評価される前にネットワークケイパビリティを取り除きます。あなたの エージェントがそれらのツールを全く必要としないときに使ってください。

​
5. ひとつのスコープキーをアタッチする

ポリシーはそれに解決されるキーでのみ強制します。エージェントに、必要最小限に スコープされた独自のキーを与えます — 決してアカウント全体のキーではなく。 API Keys → New key（Developer ロール）で：
Guardrail ドロップダウンから exfil-shield を選び（guardrail_id を設定）、 Firewall policy ドロップダウンから exfil-firewall を選びます （firewall_policy_id を設定）。両方のバインディングがゲートウェイ内のキーに 存在します。明示的なガードレールアタッチメントは決してサイレントにフォールバック しません — それを無効化することがオフスイッチです。対照的に、無効化された ファイアウォールポリシーは、ワークスペースデフォルトポリシーにフォールバック します。
侵害されたキーがクォータを枯渇させられないよう credit_limit_usd を妥当な上限に 設定し（0 = 無制限）、エージェントが固定サーバーから呼び出す場合は allow_ips を バックエンドの egress IP に設定します。一時的なキーには expired_time を設定します （-1 = 無期限）。
キーは作成後の表示でマスクされます — 一度だけコピーしてください。あなたのエージェントは いまや、強制が起きていることをコードが意識することなく、すべてのリクエストを exfil-shield を通し、すべてのツール呼び出しを exfil-firewall を通して実行します。

​
6. シャドウモードでロールアウトし、それから監視する

エージェントが正当に到達するすべてのホストをまだ知らないなら、盲目的に強制しないで ください — まず観察します。完全な observe → shadow → enforce の道については 強制モードを参照してください。
1

egress ルールをシャドウする

exfil-firewall に shadow_mode: true を設定します。すべての強制判定は audit に 格下げされ、宛先とともに [shadow] would deny としてログされます。シャドウモードが オンの間、トラフィックはブロックされません。
2

フィードを監視する

Firewall → Events / Runs（Developer+）は、あなたのエージェントが当たった すべてのツール呼び出しと egress 宛先、そして何が denyされたはずかを表示します。 Guardrails → Matches（任意の Member）は、入力ガードレールが捕捉したすべての シークレットを表示します。攻撃者が到達可能なホストだけが deny されるようになるまで、 egress allow リストをチューニングします。
3

強制する

shadow_mode をオフにします。次のリクエストから統制されます — クレデンシャルは プロンプトでブロックされ、シークレットはツール引数から取り除かれ、アウトバウンド 呼び出しはあなたの許可リストに限定されます。アプリケーションの変更なし。
Matches フィードは、ガードレールに対して Log raw content がオンの場合に のみマッチした部分文字列を記録します（デフォルトはオフ — プライバシー保守的な姿勢）。 誤検出をマーク（Admin）してポリシーをチューニングします。すべてのガードレール変更は、 diff と revert ができるバージョン履歴行を書き込みます；ファイアウォールポリシーの変更は 監査証跡に記録されます。

​
7. カバレッジ一覧

持ち出しのステップそれを止めるレイヤー
クレデンシャルがリクエストに入るSecrets Blocker ガードレール（input）
モデルがシークレットを運ぶツール呼び出しを発するsanitize ファイアウォールルール（response サーフェス）
ツールが攻撃者ホストにダイヤルするegress allow / deny ルール
エージェントがクラウドメタデータまたは RFC-1918 に到達それらの CIDR をリストする egress deny ルール
fetch 形のツールがモデルに提供されるtight 自律性レベル（ツール名 deny）

​
8. 次に進む先

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

完全なマッチング言語 — egress リスト、CIDR、サニタイザ、そしてすべての判定。

データ持ち出しの脅威

このレシピが防御する攻撃の解剖、エンドツーエンド。

MCP エージェントを強化する

エージェントが MCP サーバー経由でディスパッチするすべての tools/call を統制します。

PII セーフなロギング

機密データをリクエストログと Matches フィードから締め出します。