AIエージェントの egress 制御入門 — 外向き通信を許可リストで絞るという考え方

プロンプトインジェクションの記事で、「乗っ取られたときに被害範囲を絞る」ためにネットワーク層の制御が効く、という話をしました。この記事では、その中身である egress 制御をもう一歩具体的に解説します。

egress（イーグレス）とは

egress は「外向きの通信」のことです。社内のホストからインターネットへ出ていく通信、と考えてください（逆方向＝外から入ってくる通信は ingress）。

従来のファイアウォール運用は「外から入ってくる攻撃を防ぐ」ことに重心がありました。しかしAIエージェントのリスクは逆向きです。乗っ取られたエージェントが、内側から外へ、秘密や認証情報を送り出してしまう——守るべきは egress です。

なぜエージェントは「許可リスト」と相性がよいのか

一般の社員のPCで「接続してよいサイトだけを許可リストに載せる」運用をすると、業務になりません。人間の閲覧先は多様で、日々変わるからです。

AIエージェント専用のホストは違います。健全なエージェントの接続先は、

• 利用している LLM の接続先
• 決まったいくつかのツール（コードリポジトリ、パッケージ取得先など）

と、少なく、安定しています。だから、

1. 許可リストが現実的な長さで書ける
2. リストにない宛先への接続、つまり逸脱そのものが「異常のシグナル」になる

という、人間用ホストでは成立しにくい守り方が成立します。

deny-base という強い構え

許可リスト型の egress 制御は、deny-base（デフォルト拒否）と呼ばれる構えです。

構え	既定の動き	向いている場所
allow-base	基本は通し、危険な宛先だけ遮断（ブラックリスト型）	人間が使う一般のネットワーク
deny-base	基本は遮断し、許可した宛先だけ通す（ホワイトリスト型）	エージェント専有のホスト・セグメント

deny-base は強力ですが、人間が同居するホストに適用すると通常の業務閲覧まで止まります。「どのホスト（どの回線）に適用するか」の設計がすべてです。エージェント専用のホストやセグメントを区切ることが出発点になります。

見落としやすい「抜け道」

egress を宛先ドメインで制御する場合、知っておきたい抜け道が2つあります。

• DoH（DNS over HTTPS） — 名前解決を暗号化されたHTTPSの中に隠す仕組み。これを許すと「どこへ行こうとしているか」が見えにくくなります。
• QUIC — HTTPSの新しい運び方。検査側の対応が追いつかない環境では、可視性を保つために QUIC を遮断して従来のHTTPSへフォールバックさせる運用が知られています。

また、トンネルサービスや匿名アップロードサービス（情報の持ち出しに使われやすい宛先）を明示的に拒否リストへ載せて監査に残すのも実務的な定石です。

段階導入 — いきなり遮断しない

許可リストをいきなり強制すると、必要な通信を止めて業務が壊れがちです。実務では3段階で進めます。

1. 観測（observe） — まず遮断せず、いま何が流れているかを見る。接続先の一覧がそのまま「許可リストの素案」になります
2. monitor — ポリシーを当てるが遮断しない。「もし強制したら何が止まるか」を確認してリストを詰める
3. 強制（enforce） — 確認が済んでから実遮断に切り替える

「初めて見る宛先」が現れたら要調査——という運用も、接続先が安定しているエージェントだからこそ高い精度で機能します。

正直な限界

• 宛先単位の制御です。許可した正規の宛先が悪用されるケース（許可済みサービスへ秘密を送る等）は捕捉できません
• 通信の中身まで検査するものではありません。被害範囲（blast radius）を限定する仕組みです
• ホスト側の対策（権限・サンドボックス）との多層防御が前提です

まとめ

• AIエージェントのリスクは egress（外向き通信）に重心がある
• エージェントの接続先は少なく安定 → 許可リスト（deny-base）が現実的に機能する
• DoH・QUIC などの抜け道も併せてふさぐ
• 観測 → monitor → 強制の段階導入で、業務を壊さずに絞り込む

Tate（盾）は、この考え方を「回線に挟むだけ」で実現するために設計されたアプライアンスです。仕組みは AIガードレール、導入の流れは 導入ページ をご覧ください。