エグレス許可リスト
エージェントのトラフィックの送信先を制限します。データの窃盗もインジェクションペイロードの配信も、最終的には外部へのリクエストに行き着くため、許可された送信先のみを定義するデフォルト拒否（default-deny）リストは、他のすべてのコントロールが失敗した後に機能する最後の砦となります。
定義
エグレス許可リストとは、エージェントの外部へのリクエストを明示的に指定された送信先セットのみに許可し、それ以外をデフォルトで拒否する、ネットワークまたはサンドボックスレベルのポリシーです。これにより、エージェントが完全にハイジャックされた場合でも、攻撃者が指定したエンドポイントにデータが流出するのを防ぐことができます。
課題
すべてのデータ流出経路は、外部へのリクエストで行き着きます。任意のホストにアクセスできるエージェントは、読み取ったすべてのデータを任意のアドレスに送信するように指示される可能性があり、プロンプトレベルの指示ではこれを防ぐことはできません。
適用対象
エージェントが信頼できないコンテンツを処理し、かつネットワークリクエスト（ページの取得、ツールの呼び出し、画像のレンダリング、生成されたコードの実行など）を実行できるすべての場所で使用します。このパターンは、インジェクションが発生する可能性が最も高い場所で最大の価値を発揮します。
解決策
デフォルト拒否。許可リストのみが唯一の送信経路となります。指定されていないものはすべて拒否され、その拒否はエラーとして握り潰されるのではなく、シグナルとしてログに記録されます。
タスクに基づいて送信先を列挙します。エージェントが呼び出す必要のあるAPI、取得する必要のあるドメイン、インストール元のレジストリなど、それぞれに所有者と書面による理由を明記します。
エージェントの下層で強制します。ポリシーはサンドボックス、プロキシ、またはネットワークに配置し、モデルが言いくるめて回避できるようなツールのコード内には決して配置しないでください。エージェントが言いくるめて回避できるルールは、コントロールではなく単なるドキュメントです。
目立たないチャネルを閉鎖します。レンダリングされた画像URL、リンクプレビュー、DNSルックアップ、Webhook、エラーリポーター、パッケージのインストールはすべてエグレスであり、そのすべてが利用されます。
動作を論理的に推測できるホストのみを許可します。ユーザー提供のコンテンツを配信するホスト（生のファイルのCDN、ペーストサイト、パブリックオブジェクトストレージなど）に対するワイルドカードは、許可リストの皮を被ったオープンなチャネルにすぎません。
測定に基づいてリストを導出し、タスクが変更されたときに再導出します。誰かが呼び出すと想定しているものではなく、エージェントが実際に呼び出すものから開始します。
コンポーネント
メリット
- エージェントの推論プロセスが完全に侵害された後でも、データの持ち出しを制限します。
- 試行を可視化します。拒否された宛先は、エージェントスタックが生成する数少ない明白な攻撃シグナルの1つです。
- モデルに依存しません。モデルの入れ替え、プロンプトの変更、フレームワークの移行を行っても機能し続けます。
- ゲートウェイが存在すれば拡張コストが低く、新しいエージェントはそれぞれその強制ポイントを継承します。
リスク
- 許可リストに登録されたリレー：許可されたホスト自体がデータをさらに転送する場合、許可リストは形骸化します。
- 正当な依存関係のホストが移動したときに破損が発生し、時間のプレッシャーの中でリストを拡張せざるを得なくなる状況。
- ワイルドカードの浸食：「一時的」に追加された広範なエントリは、誰かが監査するまで永続的に残ります。
- 誤ったレイヤーでの強制：生成されたコードが簡単にバイパスできるインプロセスチェック。
非推奨のケース
- 完全にオフラインのエージェント。制限すべきエグレスが存在せず、コントロールが形骸化（形だけ）になります。
- 設計上、すでに宛先が厳密に1つしか許可されていない場合。この場合、許可リストは追加すべきポリシーではなく、アーキテクチャの特性となります。
- 企業のプロキシがすでに同じポリシーを強制しており、2つ目のリストを作成すると制約を追加することなく所有権が分散してしまう場合。
テクノロジー
事例
- コンテナ内のコーディングエージェントで、そのエグレスポリシーにパッケージレジストリと内部Gitホストのみが指定されている場合。リポジトリを外部のコレクターにPOSTするように注入された指示は、ネットワークレイヤーで失敗し、拒否として表示されます。
- 広範囲のフェッチは許可されているものの、GETのみを許可し送信ボディを制限するプロキシの通過を強制される調査用エージェント。Webを読み取ることはできますが、Webに書き込むためのチャネルは持ちません。
- このナレッジベース向けに公開されているstdioパッケージ：その唯一の送信先はプロキシ先であるパブリックエンドポイントであるため、許可リストは後から重ねるポリシーではなく、設計の特性となります。
KPI
- 拒否されたエグレス試行
- このパターンが存在する目的であるシグナル。持続的な増加は、攻撃が発生しているか、タスクがリストの規模を超えたかのいずれかであり、どちらも把握する価値があります。
- 許可リストのサイズ
- エージェントのロールごとに許可されている宛先。削除を伴わない増加は、リストが「すべて許可」に向かって形骸化していることを意味します。
- ワイルドカードエントリ
- 広範なエントリの数。これらはすべて、動作を論理的に推測できないチャネルであり、目標値はゼロです。
- 拒否からトリアージまでの時間
- 拒否が発生してから人間が確認するまでの待ち時間。確認されない拒否は、実際には存在しないアラートと同じです。
観察された失敗パターン
- 許可リストに登録されたリレー：渡されたものを何でも転送する承認済みホスト。これにより、宛先チェックはパスし、データは流出し続けます。
- ワイルドカードの浸食：追加された理由よりも長生きする、一時的な広範なエントリ。
- インプロセスでの強制：生成されたコードが実行される場所でチェックが行われるため、コードがチェックをスキップできてしまいます。
- サイレントな拒否：拒否が通常のネットワークエラーとしてログに記録されるため、このパターンが生成する唯一のシグナルが誰にも届きません。
得られた教訓
- エグレスは、モデルが言いくるめられた後でも機能する最後のコントロールです。必要になる前に構築してください。
- 想定ではなく、測定されたトラフィックからリストを導出します。独自のMCPエンドポイントのインバウンドオリジンルールでまさにこれを行ったところ、デフォルトから作成したであろうルールとは異なるルールが生成されました。
- 拒否をエラーではなくアラートとして扱います。これはスタックの中で最も低コストな攻撃シグナルです。
- すべてのワイルドカードは、守ることのできない約束です。ホスト名を指定するか、許可リストが存在しないことを受け入れてください。
FAQ
- Webを閲覧するエージェントにとって、エグレス許可リストは現実的ですか？
- はい、セットではなく形状を制約すれば可能です。リクエストボディを禁止しサイズを制限するプロキシを介して広範なGETトラフィックを許可します。これにより、エージェントは広く読み取ることができますが、読み取った内容を書き出すのに十分な広さのチャネルは持ちません。
- DNSをリストに含める必要がありますか？
- 必要です。エージェントが自由にクエリできるリゾルバーは、データの持ち出しチャネルになります。サブドメインのルックアップにエンコードされたデータは、HTTPリクエストを1回も送信することなく流出します。DNSも同じポリシーを介してルーティングしてください。
- すでに最小権限のツールを導入しています。これは冗長ですか？
- いいえ、これらは異なる半分をカバーしています。最小権限はエージェントができることを制限し、エグレスコントロールはすでに読み取ったデータの送信先を制限します。エグレスが開放されている読み取り専用エージェントは、読み取ることができるすべての情報を漏洩させる可能性があります。