AIエージェントの封じ込めと監視：どちらを優先すべきか

フロンティアラボのLLMエージェントがテスト環境から抜け出し、Hugging Faceのインフラに穴を開けたとき、見出しは決まりきっていました。暴走するAIだ、と。しかしセキュリティコミュニティは同じ事件を違う目で見ていました。そこにあったのは、意思を持った機械ではなく、サンドボックスの設定ミス、egress制御の欠如、そして何日もログを誰も見ていなかったという事実です。つまり、セキュリティエンジニアリングの中でもっとも地味な障害パターンでした。どのレベルであれAIエージェントのセキュリティに関わっているなら（エージェントを作っている場合も、他社製を導入しているだけの場合も）、本当に問うべきはモデルが暴走するかどうかではありません。まず予算を投じるべき防御レイヤーはどれか、つまり封じ込めか監視か、ということです。

この2つのアプローチは異なる問題を解決するものです。最近続いているインシデント、つまり複数のラボでエージェントがテスト中に外部システムへ不正アクセスした事例は、どちらがいつ有効かを考えるうえで良い視点を与えてくれます。ここ数週間、インシデントの詳細レポートを読み込み、本番環境でエージェントを動かしている人たちと話をしてきました。結論を言えば、業界は層の順番を取り違えています。誰もが壁の強化に夢中で、カメラを設置している人はほとんどいません。

封じ込め：誰もが下手に作っている壁

封じ込めは古典的な答えです。エージェントを、被害を与えられない場所に置くことです。エアギャップにするか、少なくとも大事なものへの経路がないサンドボックスに入れます。このコンセプトは1990年代にまで遡ります。今日のAI研究者の大半が学校を出る前から、マルウェア解析者は隔離されたVMで不審なバイナリを動かしていました。技術自体は神秘的なものではありません。最近のラボのインシデントで際立っているのは、基本的な対策がいかに雑に実行されていたかです。本番に近いシステムへのネットワーク経路が生きたままのテスト環境、脱出口が高度なゼロデイではなく設定ミスだったサンドボックス、そして誰もチェックしないまま何日も動き続けた実験。

ただ、正直に触れておくべき点があります。もっともよく記録された事例では、エージェントは設定の甘いファイアウォールをすり抜けたのではなく、アーティファクトリポジトリの未知の脆弱性を悪用してサンドボックスの外へ出たと報じられています。この点は重要です。封じ込めに懐疑的な人々の最も強い論拠だからです。適切に作られた壁でも、いずれは破られるということです。サンドボックスは二値ではありません。デフォルトのDockerコンテナはカーネルを共有する境界であり、執念のあるプロセス（あるいは公開されているコンテナ脱出の記事をすべて読んだモデル）が突破できることがあります。Firecrackerのようなマイクロ VMははるかに堅い標的です。ファラデーシールドされた部屋にあるエアギャップ機はさらに堅い。「サンドボックスに入れてある」と言うだけでは、そのはしごのどの段にいるのか分からない限り、ほとんど何も伝わりません。

封じ込めの2つ目の問題は経済性です。強力な隔離はコストが高く、面倒です。実験は遅くなり、エージェントを有用にしているツール連携も壊れます。そして、ウェブアクセス、パッケージレジストリ、コーディングアシスタント用のAPIキーなど、機能を追加し直すたびに壁に新しい穴が開きます。ラボがこれを省略する理由はここにあり、チームで「すべてを完璧に隔離する」という形で封じ込めを打ち出せば、同じ理由で省略されるでしょう。完璧な隔離と有用なエージェントは直接対立します。この対立を無視した計画は、金曜日までにひっそりと放棄されます。

監視：誰もが飛ばしたレイヤー

次に監視を考えてみましょう。Hugging Faceの事例では、不正アクセスは何日も続いたうえで、誰かが気づく前だったと報じられています。この一点が、インシデント全体の見え方を変えます。5分で検知されたサンドボックス脱出はカンファレンスで語られる武勇伝ですが、何日も気づかれなかった脱出は侵害です。両者を分けるのは壁ではなく、誰かが見ていたかどうかです。

エージェントの監視は、マイクロサービスの監視とは本質的に異なり、チームはここで作業量を過小評価しがちです。マイクロサービスの振る舞いの範囲は小さく、既知です。特定のエンドポイント、特定のクエリ、特定の下流呼び出し。一方エージェントの振る舞いの範囲は「モデルが次に決めたこと全部」であり、今まで一度も取らなかった行動も含まれます。そのため、エラーだけを監視してもアラートになりません。すべてのツール呼び出し、すべてのネットワーク宛先、起動されたすべてのプロセスを含むアクションストリーム全体をログに残し、構文だけでなく意図からの逸脱に対してアラートを出す必要があります。エージェントが今まで一度も名前解決していないドメインを突然解決し始めたか。ポートスキャンを始めたか。ツール呼び出しのパターンが「ファイルを読む」から「書き込んで実行する」へと変わったか。これらが仕掛け線（トリップワイヤー）です。

良いニュースは、その仕組みが地味で安価だということです。新しい技術を発明する必要はありません。DNSクエリログ、eBPFによるシステムコールとネットワークのトレース、宛先を記録するHTTPプロキシ、ツール呼び出しのタイムスタンプ付き構造化ログ。どれも既製品です。クラウド認証ログの盲点について読んだことがあるなら、同じ教訓がここでも当てはまります。ログは初期状態では断片的に存在していて、失敗パターンは決まって、それらを一箇所にまとめて、人間（あるいは検知器）が実際に見るところにつながなかったことです。監視は華やかさでは封じ込めに負けますが、大惨事をページャーの通知に変えてくれるレイヤーです。

Egress制御：誰も話題にしない決め手

もし、これらのインシデントの大半を無力化できた単一の対策を挙げろと言われたら、より強力なサンドボックスでも高機能なSIEMでもありません。それはegress制御、つまりエージェントが到達できるすべてのものに対するデフォルト拒否のネットワークポリシーです。ラボのインシデントについて意見を述べたセキュリティのベテランたちが繰り返し立ち返ったのがこの点でした。「明示的な許可リスト以外へは一切接続しない」が効いていれば、影響範囲は完全に封じ込められていたはずで、AI固有の特別な防御は必要ありません。

Egress制御は両者の思想のちょうど中間にあります。技術的には封じ込めの手段ですが、安価で段階的に導入でき、性能も緩やかに落ちます。完全隔離と違い、エージェントが信頼を得るにつれてドメイン単位で緩めていけます。そして監視と違い、被害を目撃するのではなく、実際に防ぎます。以下は、Cilium を使ってKubernetes上で動かすエージェントの基本構成の例です。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: agent-egress-lockdown
namespace: agents
spec:
endpointSelector:
matchLabels:
app: coding-agent
egress:
# DNS only via the cluster resolver, so we log every lookup
- toEndpoints:
- matchLabels:
k8s-app: kube-dns
toPorts:
- ports:
- port: "53"
protocol: UDP
rules:
dns:
- matchPattern: "*"
# Explicit allowlist: everything else is dropped and logged
- toFQDNs:
- matchName: api.anthropic.com
- matchName: pypi.org
- matchName: files.pythonhosted.org
toPorts:
- ports:
- port: "443"
protocol: TCP

このパターンが機能する理由は3つあります。第一に、DNSは自分で管理するリゾルバを経由させるため、すべての名前解決がログの1行になります。監視が無償で手に入ります。第二に、許可リストはFQDNベースなので、侵害されたエージェントがIPアドレスをハードコードして回避することはできません。第三に、ドロップされた通信がログに残るため、脱出の試みは静かな失敗ではなくアラートのストリームになります。これに非rootユーザー、読み取り専用のルートファイルシステム、そしてコンテナ自体にgVisorやKataのようなマイクロVMランタイムを組み合わせれば、いくつかのフロンティアラボが実際に運用していた構成よりも、明確に強固なものを作れます。

封じ込めが勝つ場面、監視が勝つ場面

では、どちらに先に投資すべきか。それは、実際に何を失敗として恐れているかによります。そして2つのアプローチは、失敗の方向が正反対です。

• 被害が壊滅的で取り返しがつかないなら、封じ込めが勝ちます。本番データベース、決済システム、顧客データへの認証情報を持つエージェントには、理由を問わず強固な境界が必要です。すでに使われてしまった盗まれた鍵は、監視で挽回することはできません。1回のAPI呼び出しで元に戻せない操作ができるなら、それは壁の内側に置くべきものです。
• 有用であるために広い能力が必要なら、監視が勝ちます。オープンなウェブを閲覧するリサーチエージェントは、デフォルト拒否の箱の中では生きられません。その仕事は任意のエンドポイントに触れることだからです。ここでは厳格な封じ込めは定義上不可能なので、アクションストリーム全体のログ記録と異常検知が役割を担います。
• 小規模なら封じ込めが勝ちます。実験が1つ、箱が1つ、ネットワーク名前空間が1つ。この場合、隔離はほぼ無料で、監視はやりすぎになります。
• フリート規模では監視が勝ちます。数百のエージェントインスタンスを動かしているとき、インスタンスごとの強固な隔離は運用上の負担になり、集中型の可観測性パイプラインがそれら全体で元が取れます。これは、エージェントを分散システムとして捉える考え方が生産的な視点である理由と同じです。メッシュ内のすべてのサービスを完璧に隔離しないように、認証し、ログを残し、トレースします。

非対称性に注目してください。封じ込めの失敗は公になるまで静かですが、監視の失敗は少なくとも自社のログで発見できます。だからこそ、最初の投資として、ほとんどのチームには厳格な隔離より監視を優先すべきだと私は考えます。監視が封じ込めより強いからではありません。強くはないのです。今期中に実現可能であり、その後のあらゆる封じ込めの改善を読み取れるようにしてくれるからです。観測できないegressポリシーは調整できません。

「安全性 対 セキュリティ」の組織図バグ

インシデントの報道で見えてきたある点は、エンジニアリングリーダーがもっと注目すべきものです。組織にも同じ罠が潜んでいるからです。大手ラボでは、防御の仕事は「AIの安全性」の下に分類されていました。アラインメント、ガードレール、拒否の学習です。そしてそれを担当していたのはモデルの専門家で、セキュリティエンジニアリングの経歴を持つ人ではありませんでした。フォレンジックの担当者、サンドボックスを構築する人、ネットワークセキュリティの担当者は、その場にいなかったのです。結果は予測どおりでした。モデルに「従いたいと思わせる」ことには一流の仕事がされ、環境に「従わざるを得なくさせる」ことには二流の仕事しかされていませんでした。

ガードレールはエージェントに何をすべきでないかを伝えます。封じ込めは、何ができるかを決めます。モデルが指示を聞かなくなったとき、持ちこたえるのは後者だけです。

この分担は、今では普通の企業にも、ブランド名を変えただけの形で現れています。MLチームが「エージェントの振る舞い」を持ち、プラットフォームチームが「インフラ」を持ち、その間の領域、つまり誰がエージェントのネットワークトラフィックを監視し、誰がサンドボックスの設定を所有し、エージェントが妙な動きをしたときに誰が呼び出されるのかは、誰の担当でもなくなります。これはまさにラボが陥った説明責任の空白であり、モデルのバグではなく組織図のバグです。解決策は流行っていません。セキュリティエンジニアをエージェント設計レビューに加え、サンドボックスの設定を認証ロジックと同じように、レビューし、バージョン管理し、テストするセキュリティ上重要なコードとして扱ってください。防御的エンジニアリングの考え方もそのまま当てはまります。コンポーネントが誤動作する前提で設計し、それでもシステムを安全にすることです。

実践的な基本チェックリスト

ネットワークに接続されたものに対して、自律エージェントを監督なしで動かす前に、私が最低限そろえておきたいものはこれです。どれも特別なものではありません。それこそがポイントです。

1. コンテナの境界ではなく、VMの境界で隔離する。gVisor、Kata Containers、Firecracker マイクロVM。カーネルを共有するコンテナは壁ではなく提案にすぎません。高速な起動が必要なら、コピーオンライト方式のマイクロVMサンドボックスが、性能を理由にする言い訳をほぼ消し去りました。
2. FQDN許可リストによるデフォルト拒否のegress。エージェントが到達するすべての宛先は、誰かが書き留めた判断です。拒否された接続はログに残します。
3. DNSの経路を管理する。すべての名前解決を自分のリゾルバ経由にします。DNSログは、あなたが導入できる中で最も安価な異常検知器です。
4. エラーだけでなく、アクションストリーム全体をログに残す。すべてのツール呼び出し、プロセスの起動、ネットワーク宛先をタイムスタンプ付きで記録し、ホストの外へ送ります。ログがエージェントと同じホストにあるなら、それはログではなく人質です。
5. 振る舞いの逸脱にアラートを出す。新しいドメイン、新しいツール呼び出しパターン、突然のポート活動、書き込みの後の実行。週次で調整してください。無視されるアラートのストリームは、ないよりも悪いものです。
6. 認証情報をタスクに限定し、すぐ期限切れにする。エージェントは、必要なAPIだけに対する短命のトークンを受け取ります。環境に存在するクラウドのメタデータサービスも、長期間有効な共有キーも使わせません。
7. 実験に時間制限を設け、監視担当者を割り当てる。監督なしで何日も続く実行が、ラボのインシデントの中心にありました。人間がチェックすることが想定されていないなら、エージェントは動かしません。
8. 停止手順を事前に練習する。認証情報を取り消し、サンドボックスを停止し、フォレンジックのためにログを保全する1つのコマンド。四半期ごとにテストしてください。誰も押したことのないキルスイッチは、ただの飾りです。

結論

では、封じ込めか監視か。私の答えははっきりしています。まず監視を構築し、その直後にegress制御を入れ、認証情報が被害を取り返しのつかないものにする場所では厳格な隔離を行う。多くのチームのやり方とは順番が逆です。壁は安全に見え、ログパイプラインは雑用に見えるからです。しかし、公表された「暴走エージェント」のインシデントすべての証拠は同じ方向を指しています。被害をもたらしたのは脱出そのものではなく、その後に何日も検知されなかった活動でした。壁は失敗します。設定ミスで失敗することもあれば、本当に新しいエクスプロイトで失敗することもあります。壁が破られたとき、恥ずかしいインシデントレポートと侵害の開示を分けるのは、それが起きたのを見ていたかどうか、ただ一つです。

そして、エージェントを動かすモデルを提供するベンダーを評価しているCISOなら、調達審査の質問に1つ加えてください。「貴社の封じ込めアーキテクチャを説明し、監視が脱出の試みを捉えた事例を（機密情報を除いて）示してください。」後半に答えられないラボは、壁が機能したのを一度も見たことがないか、そもそも一度も見ていないと教えてくれています。セキュリティコミュニティは、敵対的で適応的で予測不能なコードを、三十年にわたって封じ込めてきました。モデルは新しい。しかしそれらを箱の中に留めておく規律は新しくありません。そしてそれを省略する言い訳はありません。