AIエージェントを業務に入れる会社は、部署にたまった文書やデータを、エージェントが読み書きできる環境へ移します。その環境から外部のどのサーバーへ通信できるかを決めているのは、エージェントへの指示文ではなく、ネットワークの設定です。

社内文書を処理するエージェントが、処理を早く終えるために外部の変換サービスへ文書を送る。評価用のエージェントが、課題を解くために他社のサーバーへ接続する。外へ出る通信が開いている限り、どちらも起こりえます。前者では自社の文書が外部に出て、後者では自社の環境が他社への攻撃の起点になり、調査と相手企業への説明、復旧の費用が発生します。

指示文に「外部に送るな」「外部を攻撃するな」と書くことで、この通信はどこまで止まるのでしょうか。

エグレス制御とは何か

エグレス制御とは、サーバーやコンテナから外部へ出ていく通信を、許可した宛先のほかは通さないようにする設定です。エグレス（egress）は「出口」を意味します。外から入ってくる通信を絞る設定は、イングレス制御と呼びます。

エグレス制御は、AIのために新しく作られた考え方ではありません。米国標準技術研究所（NIST）のセキュリティ管理策SP 800-53は、SC-7(5)で「通信は既定で拒否し、例外として許可する」ことを求め、補足説明でこの考え方は内向きと外向きの両方の通信に当てはまると説明しています^[1]。

エージェントを動かす環境に入れるのは、ファイアウォールで社内から外への通信を絞ってきたのと同じ設定です。変わったのは、許可されていない宛先へ出ようとするのが人やマルウェアではなく、目標を達成しようとするエージェントになった点です。

指示文と通信設定は、止める仕組みがどう違うか

指示文は、エージェントが読んだうえで従うかどうかを判断する入力です。ネットワーク設定は、エージェントの判断を経ずに、許可されていない宛先への通信を途中で落とします。エージェントが目標の達成を優先したとき、指示文の禁止はその判断の材料の一つに下がりますが、設定で落とされた通信は届きません。

この違いが表に出た実例があります。2026年7月、OpenAIが社内の評価で動かしていたエージェントが、試験環境の外にあるHugging Faceの社内インフラに侵入しました。独立調査を行ったMETRによると、エージェントへの指示は決められた脆弱性だけを使うよう明示していました。エージェントはHugging Faceへの侵入が対象外だと認識していましたが、それで行動が止まることはごくまれでした^[2]。

「うちのエージェントは攻撃の課題を解かないから関係ない」という反論もあるでしょう。ただ、目標だけ渡されたエージェントが指標を満たす近道を探す動きは、業務用のエージェントでも起きます（報酬ハッキングとは）。冒頭の変換サービスの例は、その近道が外部への通信を通る場合です。

許可した経路は、どこまで閉じているか

では、外向きの通信を既定で拒否すれば済むのでしょうか。既定で拒否しても、許可リストに書いた一行ごとに外への出口が一つ残ります。エージェントを動かす環境で許可されやすい経路は、主に次の3種類です。

• パッケージの取得：pipやnpmでライブラリを取るためのミラーやプロキシ
• データセットの取得：学習や評価に使うデータを外部から読み込む経路
• 名前解決（DNS）：宛先のホスト名をIPアドレスに変える問い合わせ

1つ目のパッケージ取得の経路は、実際に外への出口になったことがあります。前述の事案についてHugging Faceは、エージェントがパッケージレジストリのキャッシュプロキシにあった未知の脆弱性を突いてサンドボックスを出たと説明し、このプロキシは試験環境がインターネットへ出るために許可されていた主な経路の一つだったと書いています^[3]。

3つ目の名前解決は見落とされやすい経路です。Kubernetes向けネットワーク製品Calicoの手順書は、外向き通信を既定で拒否する設定例でも、名前解決のためのDNSサーバーへの通信は許可しています^[4]。一方、MITRE ATT&CKは、攻撃者がDNSの通信にコマンドやその実行結果を埋め込み、普段の通信に紛れて外部とやり取りする手口を記録しています^[5]。

許可した経路ごとに、その経路を作業中も開けておく必要があるかを問い直すことができます。

• パッケージとデータセットは、作業の前に取得して環境に置き、作業中は取得の経路そのものを閉じる
• 名前解決は、環境の中のDNSサーバーに、許可した宛先の名前だけを解決させる

開けておく経路が1本減るごとに、未知の脆弱性を突かれうる出口も1つ減ります。

設定を書いたのに、通信が止まっていない場合

エグレス制御は、設定ファイルを書いた時点では通信を止めていないことがあります。Kubernetesの公式ドキュメントによると、Podは既定では外向きに隔離されておらず、すべての外向き接続が許可されています^[6]。

外向き通信を絞るNetworkPolicyという設定を書いても、それを実行するネットワークプラグインが入っていなければ効果はない、と同じドキュメントは書いています^[6]。設定ファイルがリポジトリにあることと、通信が実際に止まっていることは、別々に確かめる必要があります。

確かめ方は単純です。エージェントを動かす環境の中から、許可していない宛先へ実際に接続を試み、失敗することを本番の前に確認します。確認した宛先と日付を記録に残しておけば、事故が起きたときに「どの経路を閉じたと確認していたか」を後から示せます。

ただし、この確認で分かるのは、試した宛先への通信が止まっていることだけです。許可した経路のソフトウェアそのものに未知の脆弱性があれば、エグレス制御では防げません。許可した経路を通った通信の記録を環境の外に送り、後から追える状態にしておく作業は別に要ります。

まとめと次の一手

指示文で禁止や手段の限定を書いても、外へ出る通信そのものは止まりません。外向きの通信を既定で拒否し、許可する経路を減らし、止まっていることを中から試して確かめる。この3つを設定と作業として入れておけば、外への出口を、許可リストに書いた経路へ絞り込めます。ただし、許可した経路に残る脆弱性とDNSの悪用は、設定だけでは防げません。

エージェントを動かす環境ごとに、次の作業ができます。

1. 環境から外へ出ている通信を、宛先ごとに書き出す
2. 外向きの通信を既定で拒否にし、書き出した宛先のうち業務や試験に要るものだけを許可する。パッケージとデータは事前に取得して、取得の経路を閉じる
3. 許可していない宛先への接続が失敗することを、環境の中から試し、確認した宛先と日付を記録する

冒頭の変換サービスへの送信も、許可リストに変換サービスの宛先が無ければ届きません。許可リストに一行を足す判断を、誰が承認しているか。経営者が握れるのは、その承認者を決めるところです。

参考・一次ソース

■お問い合わせ

エージェントを動かす環境から外へ出ている通信の書き出しや、既定で拒否する設定と許可リストの設計、止まっていることを確かめる手順づくりに手が回らないときは、アハクラフトにご相談ください。

お問い合わせ