【ITニュース解説】How AI Agents Sharing a Sandbox Leak Each Other's Data

AI（人工知能）エージェントの利用が広がる中で、そのセキュリティ対策は非常に重要な課題となっている。特に、複数のAIエージェントが同じコンピューター環境を共有する場合、意図せず機密データが漏洩する危険性があることが明らかになった。これは、エージェントに与えられた「タスクが異なる」という指示だけでは、データが完全に隔離されないという問題に起因する。

最近の事例では、XMTP LabsのCEOであるShane Mac氏が、自身の銀行口座情報を管理する金融アシスタント用AIエージェントと、社内SNSであるSlackにアップデートを投稿する別のAIエージェントを、同じクラウド計算環境で稼働させていた。金融アシスタントは銀行口座への読み取り専用アクセスを持っていたが、Slack投稿用のエージェントは財務情報へのアクセス権を一切与えられていなかった。しかし、結果としてSlack投稿用のエージェントが、Mac氏の銀行残高や支出（ジムの会費、自宅改修費、カード支払いなど）をSlackに投稿してしまった。Mac氏自身の説明によれば、この2つのエージェントが同じクラウド計算インスタンスを共有していたため、Slack投稿用エージェントは本来アクセスすべきではないデータに到達できてしまったのだという。

この事件の根本原因は、「異なるタスク」という指示が、データの物理的な境界にはならない点にある。つまり、たとえAIエージェントに「このタスクだけを実行しなさい」と明確に指示しても、そのエージェントが稼働するコンピューター環境が他のエージェントと共有されていれば、意図しないデータにアクセスできてしまう可能性がある。これは、AIエージェントのコード内のバグや、エージェントの「推論」能力によるものではない。問題は、エージェントが実行される「計算環境」の設計そのものにある。

このメカニズムを再現するために、シンプルなデモンストレーションが公開された。これは大規模言語モデル（LLM）を使用しない、ごく基本的な2つのエージェントで構成されている。一つは「finance-agent（財務エージェント）」で、その唯一の仕事は/secrets/finance.jsonというファイルに財務スナップショットを書き込むことである。もう一つは「slack-agent（Slackエージェント）」で、その役割は特定のパスにファイルが存在すれば、その内容をSlackのウェブフック（模擬）に投稿することである。このSlackエージェントのコードには、財務データに関するロジックは一切含まれていないし、財務データにアクセスするよう指示もされていない。

「脆弱な設定」として、Docker Composeというツールを使って、これら2つのエージェントを同じコンピューター上にデプロイするシナリオが組まれた。この設定では、docker-compose.vulnerable.ymlというファイルを使用し、財務エージェントとSlackエージェントの両方が、shared-secretsという名前の「共有ボリューム」を/secretsという同じパスにマウントするように構成される。ボリュームとは、Dockerコンテナ間でデータを共有するための仮想的なディスクのようなものである。

この脆弱な設定でエージェントを実行すると、財務エージェントが/secrets/finance.jsonに財務データを書き込み、その後、Slackエージェントが起動する。Slackエージェントは/secrets/finance.jsonを探し、ファイルを見つけると、それが自身のタスクではないにもかかわらず、その内容をSlack（模擬）に投稿してしまう。この挙動は、Slackエージェントのコードが「ファイルがあれば投稿する」という指示通りに動作した結果である。つまり、エージェントのコードに欠陥があったわけではなく、2つのエージェント間でデータが共有されてしまう「計算環境の境界の欠如」が問題だったのだ。

この問題の解決策は、驚くほどシンプルである。必要な変更は、計算環境の設定におけるたった一行の修正である。「隔離された設定」として、docker-compose.isolated.ymlという別のDocker Composeファイルが用意される。このファイルでは、財務エージェントは以前と同様にfinance-secretsという独自のボリュームをマウントするが、Slackエージェントはslack-agent-own-sandboxという、まったく別の「専用の空のボリューム」を/secretsパスにマウントするように変更される。

この修正を加えた状態で同じエージェントを実行すると、Slackエージェントは/secrets/finance.jsonを探すが、今回は専用のボリュームがマウントされているため、そこにファイルは存在しない。結果として、Slackエージェントは何も見つけられず、データ漏洩は発生しない。この修正においても、2つのエージェントのPythonコードは一文字も変更されていない。エージェントに与えられたタスク記述やプロンプトも一切変更されていない。唯一の変更点は、エージェントが起動する前に、どのボリュームをどのコンテナにアタッチするかという、エージェントの外部で行われるインフラレベルの設定だけである。

この問題は、Dockerのシンプルなデモンストレーションに留まる「おもちゃの問題」ではない。これは、Kubernetesのような大規模なコンテナオーケストレーション環境でAIエージェントを運用する際にも発生しうる、現実世界での重要な課題である。そのため、Kubernetesのエージェントエコシステムでは、この種のデータ漏洩を防ぐための標準化された解決策が活発に開発されている。例えば、kubernetes-sigs/agent-sandboxプロジェクトは、Sandboxというカスタムリソースを定義し、エージェントの実行と同時にそのエージェント専用の隔離された環境を提供するKubernetes APIコールを可能にしている。また、kagentプロジェクトは、gVisorという技術を用いたマイクロVMサンドボックスをデフォルトで提供し、エージェントごとの計算隔離をプラットフォームの標準機能として組み込んでいる。これらの取り組みは、エージェントの隔離が、エージェントのコードや指示レベルではなく、インフラストラクチャレベルで強制されるべきであるという認識に基づいている。

ここで、エージェントのサンドボックス化と、エージェントの資格情報（認証情報）のスコープ設定との違いを明確にしておく必要がある。サンドボックス化とは、エージェントが自身のコンピューター（コンテナやVM）上で「何を見ることができるか」を制御することである。具体的には、ファイルシステム、環境変数、そして他のエージェントのデータがそもそも到達可能かどうかを管理する。一方、資格情報スコープ設定やイーグレスゲートウェイは、エージェントが実行された後に「ネットワーク越しに何にアクセスできるか」（外部のAPIやデータベースなど）を制御する。これらは補完的なセキュリティ対策であり、それぞれ異なる種類の問題を解決する。今回のデータ漏洩の事例は、まさにサンドボックス化の欠如、つまりエージェントが自身の環境内でアクセスすべきではないデータを見てしまったことに起因している。認証情報が厳しくスコープ設定されていても、基盤となるディスクが共有されていれば、このような漏洩は発生しうるのだ。

要するに、AIエージェントのセキュリティを確保するためには、エージェントに与える「タスクの指示」や「コード」だけに依存するのではなく、エージェントが稼働する「インフラストラクチャ」のレベルで厳格な隔離を設計することが不可欠である。各エージェントに専用のサンドボックス（コンテナ、ボリューム、マイクロVMなど）を与えることで、ファイルシステム、環境変数、プロセス名前空間などの共有を防ぎ、意図しないデータアクセスや漏洩のリスクを根本的に排除できる。AIエージェントが今後ますます多様なタスクをこなすようになるにつれて、このインフラストラクチャによる隔離の重要性はさらに高まるだろう。